会，rabbitmq多节点监听同一队列时必发生重复消费；根本原因是消息重入队后被不同节点处理，需结合redis幂等+唯一messageid+合理过期时间防控。
会，而且这是 RabbitMQ 默认行为下的必然结果，不是“会不会”的问题，而是“一定会发生”的前提条件没被约束。
为什么多个 Spring Boot 节点会同时消费同一条消息
RabbitMQ 本身不感知消费者是不是集群、是不是同一应用的多个实例。它只按「队列—消费者」关系分发消息：只要多个节点监听同一个队列（queueName），RabbitMQ 就会轮询（Round-Robin）或根据 prefetchCount 分配消息——每条消息只会投递给一个消费者，但这个“一个”是随机落在某个节点上的。
真正导致「重复消费」的，不是消息被发给多个节点，而是：某个节点消费失败/崩溃/未 ACK，RabbitMQ 把消息重新入队后，下一次又被另一个节点拉走处理。
- 你看到的“重复”，本质是同一消息在不同时间点被不同节点各处理了一次
- Spring Boot 默认开启 auto-ack（自动确认），一旦消息被取走，立刻从队列删除——哪怕业务还没开始跑，这反而掩盖了问题，但更危险
- 如果你用的是
@RabbitListener+ 手动 ACK，又没做幂等，那两个节点都成功处理了同一条订单 ID，就真扣两次款了
手动 ACK 不等于防重复，只是把控制权交给你
开启手动 ACK（acknowledge-mode="manual"）只是让 RabbitMQ 等你调用 channel.basicAck() 才删消息，但它不保证你不会在两个节点上都调用成功。
典型错误写法：
@RabbitListener(queues = "order.queue")
public void onOrder(Order order, Channel channel, Message message) throws IOException {
try {
orderService.handle(order); // 业务逻辑
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
} catch (Exception e) {
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
}
}
这段代码在单节点下能避免丢失，但在多节点下毫无防重能力——两个节点拿到同一条消息（比如因前次 nack 后重入队），都会走通 orderService.handle()，然后各自 ack。
- 必须配合全局唯一标识（如
message.getMessageProperties().getMessageId()或业务自定义orderId） - 必须在
basicAck()前完成去重判断，且该判断要跨节点共享状态（Redis 是最常用选择） - 不能依赖本地内存或数据库主键唯一约束来兜底——主键冲突会抛异常，但此时
basicNack(..., true)可能已触发重试，形成死循环
Redis 去重不是加个 set 就完事，过期时间得算准
用 Redis 记录已消费的 messageId 是主流做法，但常见疏漏是：SET key value EX 600 这种固定 10 分钟过期，可能根本不够。
你需要对齐的是：业务最长可能耗时 + 消费者最大重试窗口 + 网络抖动容忍度。
- 比如订单支付回调平均耗时 2s，但极值 8s，你设
EX 30（30 秒）就可能刚过期，另一节点就进来了 - 如果消费者配置了重试 3 次、间隔 5s，那整个生命周期至少要覆盖 15s + 处理时间，建议按 5× 最长预期耗时设过期
- 别用
SETNX单独判断再SETEX—— 非原子操作，两个节点可能同时通过判断；改用SET key value EX 300 NX - Redis 宕机不是“降级选项”，是故障点：必须有 fallback（比如记录到本地磁盘临时文件 + 定时补偿），否则直接放弃去重
真正容易被忽略的点是：消息 ID 的来源不可信。RabbitMQ 的 messageId 默认为空，靠生产者设置；如果生产者没设或设得不唯一（比如用时间戳+随机数但并发高时碰撞），Redis 去重就完全失效。必须在发送端强制生成 UUID，并透传到消费端校验。
