Nest.js微服务Redis传输下多实例重复订阅消息问题咨询

重复消费是原生Redis Pub/Sub的固有机制导致，并非配置错误。原生Redis Pub/Sub采用广播分发逻辑，所有订阅同一Channel的客户端都会收到全量消息，本身不提供竞争消费、负载均衡能力，天然无法适配同服务多实例水平扩展的微服务通信场景。

按改造成本、适用场景排序：

• 最低成本改造（保留Redis技术栈）：使用Redis Stream替换原生Pub/Sub。Redis Stream原生支持消费组机制，同一消费组内的多实例以竞争模式消费消息，自动负载均衡，不会重复投递。Nest v8及以上版本官方微服务模块已原生支持Redis Stream模式，无需引入第三方依赖。
• 生产环境通用首选：RabbitMQ。Nest官方原生适配，自带竞争队列、轮询分发、死信队列、消息确认等完整能力，同一队列绑定多个消费者时默认轮询投递，无重复消费问题，运维成本中等，适合绝大多数业务场景。
• 高吞吐场景：Kafka。Nest官方原生适配，基于消费组实现负载均衡，吞吐量极高，适合日志流、高并发异步事件场景，运维成本相对较高。
• 低延迟云原生场景：NATS。Nest官方原生适配，内置队列订阅模式，部署轻量、延迟极低，适合对通信性能要求高的云原生微服务集群。
• 同步RPC场景：gRPC。基于HTTP/2协议，内置客户端负载均衡、服务发现能力，适合强类型的服务间同步调用，不适合异步事件驱动场景。

方案1：保留Redis传输层（改造为Stream模式） #

1. 产品微服务（消费方）启动时替换默认Pub/Sub配置为Stream模式：

// 产品微服务main.ts配置
import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { randomUUID } from 'crypto';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.REDIS,
      options: {
        host: process.env.REDIS_HOST,
        port: Number(process.env.REDIS_PORT),
        // 启用Stream模式，替换默认Pub/Sub
        type: 'stream',
        // 同一微服务的所有实例必须配置相同的消费组名
        consumerGroup: 'product-service-group',
        // 每个实例配置唯一消费者ID，不要写死固定值
        consumer: `product-instance-${process.env.INSTANCE_ID || randomUUID()}`,
        autoAck: true,
      },
    },
  );
  await app.listen();
}
bootstrap();

2. API网关（发布方）配置和微服务对齐即可，无需调整消息发送逻辑。消息写入Stream后，同一消费组下仅会有一个实例收到并处理消息。

注意：切换模式前清理原有Pub/Sub的同名Channel残留数据，避免旧消息干扰。

方案2：RabbitMQ传输层（生产环境标准实现） #

1. 产品微服务启动时配置RMQ传输层，同一微服务所有实例使用相同队列名：

// 产品微服务main.ts配置
async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.RMQ,
      options: {
        urls: [process.env.RMQ_URL],
        // 同一微服务所有实例必须配置相同队列名
        queue: 'product-service-queue',
        queueOptions: {
          durable: true, // 队列持久化，避免服务重启丢消息
        },
        prefetchCount: 1, // 单消费者每次仅处理1条消息，实现公平调度
      },
    },
  );
  await app.listen();
}
bootstrap();

2. API网关侧配置相同RMQ地址与队列名即可，RabbitMQ会自动在多实例间轮询分发消息，无需额外开发负载均衡逻辑。

多实例部署通用规则 #

• 同一微服务的所有实例，必须配置完全一致的消费组/队列名，每个实例的消费者ID必须全局唯一，禁止写死固定值。
• 必须开启消息确认机制，实例宕机时未处理完成的消息会自动重新投递到其他正常实例，避免消息丢失。
• 有状态服务不要依赖消息层做粘性路由，状态数据统一下沉到分布式缓存、数据库存储。
• 原生Redis Pub/Sub仅适合配置广播、全员通知类场景，禁止用于生产环境微服务间的业务消息通信。

内容的提问来源于stack exchange，提问作者Full stack assistant