多租户Node.js+Redis并发写入竞态：幂等键无法阻止重复事务

问题背景 #

我有一个基于NestJS的多租户应用，使用Redis实现幂等键缓存，PostgreSQL采用行级锁。在高并发场景下，同一租户的两个请求间隔约50ms时，仍会生成重复事务记录——即使已尝试set nx ex、Lua脚本、select for update以及Kafka去重方案。

当前使用的幂等检查代码：

async checkIdempotency(key: string, tenantId: string) {
  const exists = await this.redis.get(`idempotency:${tenantId}:${key}`);
  if (exists) return false;
  await this.redis.set(`idempotency:${tenantId}:${key}`, 1, 'EX', 86400);
  return true;
}

仅当负载均衡后的多Node.js实例场景下才会出现重复问题，单实例运行正常。

问题解答 #

1. Redis Lua脚本在Redis集群节点间是否真的具备原子性？还是需要使用RedLock？ #

Redis Lua脚本在单个Redis节点内是原子执行的，但集群环境中，若幂等键分布在不同节点，跨节点脚本无法保证全局原子性。如果你的幂等键通过哈希槽分配固定在同一租户对应的节点上，单节点Lua脚本的原子性足够覆盖需求；但如果键可能跨节点，或需要跨多节点校验幂等性，就得用RedLock实现分布式锁的全局原子性。

另外你当前代码的核心问题是get和set是两个独立操作，存在竞态——多实例同时执行get都返回不存在，后续都会执行set，直接导致幂等失效。正确的做法是把校验和写入合并成原子操作，比如直接用SET idempotency:... 1 EX 86400 NX，返回成功则代表幂等校验通过，失败则判定为重复请求，这比分开的get+set可靠得多。

2. 幂等性检查是否应该放在API网关层面？ #

可放在网关，但并非必须，需根据场景权衡：

• 放在网关的优势：提前拦截重复请求，减少后端服务压力，适合跨实例的全局幂等校验；
• 弊端：网关需要知晓租户ID和幂等键生成规则，增加复杂度；若幂等键需结合请求体内容生成，网关解析请求体会带来性能开销，且多租户场景下网关需处理租户隔离逻辑，易与业务耦合。

如果幂等性校验和业务逻辑强绑定（比如需要结合业务参数生成幂等键），放在NestJS的拦截器/守卫层更合适，可复用业务上下文的租户ID和请求参数，实现更灵活的校验逻辑。

3. 在多租户NestJS应用中，有没有更简洁的实现模式？ #

推荐两种简洁可靠的模式：

• NestJS拦截器模式：实现全局或租户级幂等拦截器，在请求进入控制器前自动生成幂等键（比如从请求头的Idempotency-Key+tenantId生成），用Redis的SET ... NX EX原子操作做校验，校验通过才放行请求，失败直接返回重复请求响应。示例代码：

@Injectable()
export class IdempotencyInterceptor implements NestInterceptor {
  constructor(private readonly redis: RedisService) {}

  async intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const request = context.switchToHttp().getRequest();
    const tenantId = request.tenantId; // 假设从请求上下文获取租户ID
    const idempotencyKey = request.headers['idempotency-key'];
    
    if (!idempotencyKey) return next.handle();
    
    const cacheKey = `idempotency:${tenantId}:${idempotencyKey}`;
    const result = await this.redis.client.set(
      cacheKey, 
      JSON.stringify({ status: 'processing' }), 
      'EX', 
      86400, 
      'NX'
    );
    
    if (!result) {
      const cachedResponse = await this.redis.client.get(cacheKey);
      return of(JSON.parse(cachedResponse).response || { message: '重复请求' });
    }
    
    try {
      const response = await next.handle().toPromise();
      await this.redis.client.set(
        cacheKey, 
        JSON.stringify({ response }), 
        'EX', 
        86400
      );
      return of(response);
    } catch (error) {
      await this.redis.client.del(cacheKey);
      throw error;
    }
  }
}

随后在模块中注册拦截器，或用@UseInterceptors装饰器给指定控制器/方法添加即可。

• 数据库唯一约束兜底：在PostgreSQL的事务表中，给tenant_id+idempotency_key添加唯一约束，即便Redis幂等校验失效，数据库层面也能阻止重复插入。捕获唯一约束异常后，返回重复请求的响应即可。这种方式作为最后一道防线，和Redis校验配合使用，实现双重保障。

内容的提问来源于stack exchange，提问作者Sergio G