做消息队列的都知道“重复消费”四个字几乎是每个用 RabbitMQ 的团队迟早要面对的坎。我第一次踩到它是在一个订单系统上线第二周数据库里突然多出几十条重复订单排查到凌晨才定位到是消费者在业务处理完成后、发送 ack 之前瞬间崩了broker 一看消息没确认转身就把同一条消息又推给了消费者。那一次之后我才真正意识到所谓“消息只会被处理一次”在 RabbitMQ 里从来不是默认行为它默认做到的只是“消息至少会被投递一次”。这篇文章我就用实际踩坑和修复的过程把 RabbitMQ 重复消费产生的根源、幂等设计思路、三种可落地的防重方案以及从生产端到运维端的配套措施一次说透。1. 先搞明白RabbitMQ 的重复消息到底从哪来1.1 投递语义RabbitMQ 默认只保证“至少一次”很多初学者会把 RabbitMQ 想象成一个可靠到不会丢消息的组件但它的投递语义其实非常直白只要消息被写入队列broker 就会尽量保证它被消费者拿到如果消费者没有明确告诉 broker“这条消息我处理完了”broker 就会在连接恢复或消费者重新上线后把这条消息再次投递出去。这种“至少一次”的投递语义是 RabbitMQ 在可靠性和复杂度之间做的平衡。为什么 RabbitMQ 不做成“恰好一次”因为“恰好一次”需要在分布式的每一个环节都做全局协调比如 broker 和消费者之间要达成某种共识还要处理网络分区、进程崩溃、时钟漂移这些情况代价极高。RabbitMQ 面向的是“不让消息丢”这个朴素需求所以它宁可让同一条消息可能被投递多次也不允许消息凭空消失。理解了这一点你就会明白重复消息不是 RabbitMQ 的 bug而是它为了“不丢消息”付出的必然代价。1.2 消费者侧处理成功但 ack 没送出去这是我在生产环境里遇到最多的一种重复来源。消费者的处理逻辑分两步第一步执行业务代码比如往订单表里插入一条记录、调用下游接口、更新缓存第二步向 RabbitMQ 发送 ack告诉 broker“这条消息我搞定了可以删了”。问题就出在这两步之间。如果业务代码执行完毕后消费者进程突然被 kill、网络闪断、或者 JVM 发生长时间 GC 导致客户端心跳超时ack 就可能根本发不出去。broker 那边等不到确认会认为消费者处理失败于是把消息重新放入队列等待下一次消费。还有一种更隐蔽的情况消费逻辑里把 ack 放在了 try 块外面结果业务代码抛了异常ack 代码根本没执行到。或者有的同学图省事把 ack 写在了 finally 块里但业务处理是失败的消息却被确认掉了。前一种情况会造成消息重投后一种会造成消息丢失。两种都是我在代码评审里经常看到的典型错误。1.3 生产者和网络侧重复投递的隐形帮凶除了消费者自身的 ack 问题生产者也可能给重复消息“添砖加瓦”。比如你写了一个带重试机制的发送逻辑第一次调用 RabbitMQ 的 channel.basicPublish 因为网络超时报了异常你捕获异常后重试了一次但实际上第一次的请求可能已经到达了 broker服务端也成功写入了队列只是返回给客户端的确认消息在路上丢了。这个时候重试就会让同一条消息在队列里出现两份。RabbitMQ 本身不会去识别“这两条是不是同一笔业务”它只负责存储和投递所以生产端的重试逻辑如果没有配合消息唯一 ID就很容易造成源头重复。网络分区也是个容易忽略的坑。消费者和 broker 之间的 TCP 连接断开又恢复后之前未被 ack 的消息会全部重新投递。如果消费者的业务逻辑没有做幂等处理这一批消息被重复处理就是一批重复数据。1.4 死信队列与手动重投重复叠加的第三来源很多团队的代码里还有这么一层监听死信队列把死信消息重新投递到原队列或者人工介入处理。如果重投逻辑写得粗糙比如没有判断这条消息已经被消费过多少次或者重新投递时没有修改消息属性那么一条消息可能进入“消费失败 - 进入死信 - 重投 - 再消费失败”的循环每次循环都算一次重复消费。这里我见过最夸张的情况是结算系统每 10 分钟重投一次死信结果一个批处理任务被重复执行了 30 多次下游对账直接炸了。总结下来重复消费的根源无非三块broker 的“至少一次”投递语义、消费者 ack 丢失、生产端重试导致源头重复。这三块叠加在一起靠“祈祷别重复”是根本不现实的。唯一稳妥的路就是把消费端业务逻辑做成幂等——允许消息重复到来但业务结果不能因为重复而改变。2. 核心思路把“不重复”变成“可容忍重复”2.1 幂等是目的去重是手段碰到重复消费很多人的第一反应是“让 RabbitMQ 不要重复投递”。但很遗憾这事你没法通过参数配置做到RabbitMQ 压根没有“全局消息去重”这个功能。正确的思路应该反过来接受消息可能会重复这个事实在消费端把业务逻辑变得幂等。什么叫幂等就是同一个操作执行一次和执行一万次结果都一样。生活里最典型的例子是电梯按钮你按一次电梯会来连按十次电梯还是会来不会因为你的频繁按压就多来十趟电梯。放到订单场景里消费者收到一条“创建订单”的消息处理一次是创建一条订单重复处理一百次也必须是只有一条订单生效而不是一百条重复记录。幂等关注的是结果的一致性不关注执行次数。实现幂等的关键手段就是去重。去重可以放在不同层数据库层、缓存层、业务层。层的选择取决于你的业务场景和数据一致性要求没有绝对最优只有最合适。2.2 消息唯一 ID一切幂等方案的前提不管你选哪种去重方案前提都是先给消息一个全局唯一标识。这个标识最好在生产者创建消息时就生成并且塞进消息属性里。实操中我习惯在消息的 headers 里带一个messageId用 UUID 或者雪花算法生成。为什么必须由生产者生成因为只有生产者才知道这条消息对应的是哪一笔业务比如订单号、流水号、任务编号。如果让消费者自己生成那么同一条消息每次消费都会生成不同的 ID去重就无从谈起。这里有个很容易踩的坑如果把幂等键定为“消息内容本身”那么只要消息体里的任何一个字段有微小差异比如多了个空格、时间格式变了去重就失效了。所以幂等键一定要选业务层面的稳定标识比如orderId、transactionId、bizId。我一般会用“消息里实际传递的业务数据”来生成幂等键而不是直接用随机生成的 messageId。原因是 messageId 能保证消息唯一但没法保证它对应同一个人眼里的业务比如两条内容一模一样但 messageId 不同的消息实际上是同一笔操作的重试这时候业务幂等键才能把它们识别出来。2.3 选择幂等方案的四个判断标准我会在方案选型时问自己四个问题。第一个问题是业务数据最终落在哪里如果最终落在数据库那么数据库的唯一约束是天然防线如果业务依赖缓存那么 Redis 的原子操作更合适。第二个问题是对数据一致性要求有多高像订单、支付这类强一致场景必须做到“数据库层面绝对不会出现两条重复记录”那就不能只依赖 Redis因为 Redis 本身也可能丢数据。第三个问题是重复消息的并发程度高不高如果同一业务的消息可能被多个消费者实例同时拿到那就必须用具备原子性的去重手段单纯用“先查后插”的方式会存在并发竞态。第四个问题是团队运维成本能承受多少引入新的存储中间件做去重就意味着多一个系统要监控、要保证高可用。这三个问题问下来大部分场景都能快速定位到具体方案。下面我用一张表把常见方案对比一下后面再做详细说明。方案适合场景核心优势主要风险数据库唯一约束数据最终落库强一致无外部依赖需要小心异常处理约束冲突要吞掉Redis SETNX高并发、缓存型数据性能高原子性好Redis 故障会丢去重标记业务幂等表复杂状态流转可记录处理详情便于排查表结构和事务要设计好状态机校验状态有明确流转路径结合业务状态天然防重仅适用于有状态业务3. 实战演示三种常用防重复实现3.1 方案一数据库唯一约束兜底如果业务数据最终必然写入关系型数据库那么最靠谱的防重手段就是在表上加唯一索引。比如订单表除了业务主键外再建一个biz_unique_key字段并设置唯一索引。消费者在插入订单前不需要先去查询订单存不存在直接执行 insert 就好。如果这条消息已经被处理过插入就会触发唯一键冲突代码里捕获到这个异常直接当作“消息已处理”返回 ack 即可。示例代码逻辑如下伪 Java 风格public void handleOrderMessage(OrderMessage msg) { try { orderMapper.insert(msgToOrder(msg)); } catch (DuplicateKeyException e) { // 唯一键冲突说明已处理过直接忽略 log.info(duplicate order message ignored, orderId{}, msg.getOrderId()); } // 业务处理成功后再执行 channel.basicAck(deliveryTag, false) }很多人会在这里犯一个错误为了“保险”先查一次再决定是否插入。这个做法在并发场景下是有问题的。两个消费者实例同时处理同一条消息都去查都发现没有记录然后都执行插入结果还是会插出两条重复记录。除非你把“查询插入”放在同一个数据库事务里并且使用SELECT ... FOR UPDATE锁住对应记录否则“先查后插”就是给自己挖坑。直接依赖唯一约束让数据库帮你裁决才是在并发场景下最简单也最可靠的方案。这个方案的代价是订单表必须新增一个唯一索引字段。对历史表做迁移时要注意如果线上已经存在重复数据加唯一索引会失败需要先清洗数据。另外捕获到DuplicateKeyException之后一定要确认这条异常确实来自我们预设的唯一索引不要把所有数据库异常都当成重复消费吞掉否则会把真正的数据问题掩盖过去。3.2 方案二Redis SETNX 分布式去重对于不落库的异步任务比如发送短信、推送通知、更新缓存数据库唯一约束就帮不上忙了。这时候我常用 Redis 实现轻量级去重利用SETNX命令的原子性把业务幂等键作为 key只有在 key 不存在的时候才能写入成功。写入成功说明这条消息是第一次处理写入失败说明重复消息来了直接丢弃。关键代码思路如下def is_first_time(message): biz_key dedup: message[order_id] ok redis_client.set(biz_key, 1, nxTrue, ex3600) return bool(ok)这里有两个参数需要认真设计。第一个是 key 的过期时间这个时间不能太短太短的话消息在过期之后重复投递去重就失效了也不能太长太长会导致 Redis 里堆积大量过期 key。我的习惯是设置为“业务上允许消息重投的最大时间窗口”比如一个任务 5 分钟内必须完成那就设 10 分钟到 30 分钟留足余量。第二个是 key 的命名一定要带上业务前缀避免不同业务之间撞 key。这个方案最大的隐患是 Redis 本身不稳定。如果 Redis 在主从切换过程中丢失了去重 key或者应用写入成功后 Redis 发生持久化失败那么后面再来的重复消息就可能会“躲过”去重。所以 Redis 去重只适合允许极少概率重复的业务不能用于订单、支付这类强一致场景。我在金融类项目里绝对不会单独用 Redis 做防重最多把它当作前置过滤数据库唯一约束仍然是最终防线。3.3 方案三业务幂等表有些业务的处理流程不是一次插入那么简单而是会经历多个步骤和状态变化。比如退款工单要经过“创建 - 审核 - 打款 - 完成”这几个状态。这个时候用一个专门的“幂等记录表”来控制消息的处理状态比在业务表上加唯一约束更灵活。幂等表的结构大致是id、biz_type、biz_id、status、create_time、update_time。biz_type表示业务类型biz_id是业务幂等键status记录当前处理状态比如0表示处理中1表示已完成。消费者收到消息后先尝试往幂等表插入一条biz_type biz_id对应的记录状态设为处理中。插入成功说明是首次消费继续执行后续业务逻辑插入失败说明已经处理过直接返回。重点来了执行完业务逻辑后要更新幂等表里这条记录的status从“处理中”改成“已完成”。如果业务逻辑执行到一半失败了这条记录不能删除而是要保留同时把状态更新成“失败”或者直接回滚。为什么不能删我见过一个团队在失败时删除幂等记录结果分布式环境下两条消费者实例同时处理同一条消息一个还在处理中另一个已经把记录删了重试消息一来又重复执行了。保留失败记录配合定时任务清理超时记录才是安全做法。这个方案的优点是控制力强能记录每条消息的处理历史排障时一目了然。缺点是每个业务都要额外维护一张表和对应的状态流转逻辑开发成本比前两个方案高。它最适合那种业务链路长、状态多、又需要审计的场景比如支付回调、退款处理、对账任务。4. 配套措施从消费 ACK 到运维层面的保障4.1 手动 ACK 与基础 QOS 参数如果说幂等设计是“有病治病”那合理的 ack 和 QoS 配置就是“未病先防”。RabbitMQ 的消费者默认是自动 ack 模式也就是说 broker 把消息发给消费者后不管消费者处理成什么样子消息都会被标记为已确认。自动 ack 最大的问题在于“发出去”和“处理完”完全脱钩消费者的业务逻辑再健壮RabbitMQ 也无从知晓一旦消费者在处理过程中崩溃消息就永远丢了。所以生产项目里我会强制要求使用手动 ackchannel.basicConsume(queue, false, consumer)然后在业务逻辑成功完成后调用channel.basicAck(deliveryTag, false)。只有手动 ack 才能配合重投机制让“处理失败的消息”有机会被重新消费。手动 ack 的代价是代码量增加每一处消费逻辑都要注意 ack 必须在业务成功之后执行而且不能把 ack 放到 finally 里无脑执行。除了 ack还有一个参数经常被忽略basicQos里的prefetchCount。这个参数控制的是消费者本地队列里最多可以积压多少条未确认消息。如果设置得太大比如默认的无限取消费者会把大量消息拉到本地内存一旦消费者崩溃这些消息全部回到队列重新投递就会瞬间制造一批重复消息。设置得太小也不行会降低吞吐。我一般从prefetchCount10开始调整根据单条消息的处理耗时和消费者实例数量做压测找到吞吐和重投风险的平衡点。处理耗时长的任务prefetch 要更小尽量做到“处理完一条再去拿下一条”。4.2 重试机制与死信队列的配合即使加了手动 ack消费还是可能失败。失败之后是无限重试还是有限重试无限重试最坑因为如果消费逻辑有 bug消息会反复进入消费者既浪费资源又一直产生重复消费。所以我会为每个消费者配置有限重试同时在重试耗尽后把消息投递到死信队列。Spring Boot 里配置有限重试的方式很简单比如设置maxAttempts3也就是最多尝试三次消费。三次都失败后消息会被转到死信交换机再进入死信队列。死信队列里的消息不能直接丢弃应该由专门的监听器来处理记录日志、告警、或者人工介入修复后重新投递。注意重新投递死信消息之前一定要在消息属性里加一个“重投次数”标记避免进入“死信 - 重投 - 再死信”的无限循环。我有一次排查线上重复订单发现来源就是死信重投逻辑里没有判断重投次数。定时任务每小时扫描一次死信队列把所有消息一股脑重新塞回原队列。消费者的 ack 又老是超时于是同一条消息每天被重复处理几十次。加上一个简单的计数判断之后这个问题才彻底根治。4.3 生产端要做的三件事读到这你会发现重复消费的源头很可能不在消费者而在生产者。所以生产端的代码也要同步配合。第一件事发送消息前生成一个全局唯一的messageId放在消息属性里作为消息的身份证。第二件事把业务幂等键比如订单号、关联单号同步放到消息属性里消费者可以直接取用不用去解析复杂消息体。第三件事生产端开启发布确认模式也就是channel.confirmSelect()并且等待 broker 的 confirm 回执。如果发送超时或失败再进行重试但重试的时候必须复用同一个messageId和业务幂等键这样消费者才能把重试消息识别成重复消息。生产端的重试还有个细节不要每发送失败一次就立即重试建议用指数退避的方式比如第一次重试等 1 秒第二次等 2 秒第三次等 4 秒。重试次数控制在 3 到 5 次即可。重试再失败不要死循环把消息落库或者写入本地文件并触发告警让值班人员介入才是最稳妥的。4.4 安装与运维里的几个常见坑写到这里也顺带提一句部署运维层面的问题因为这些坑直接会诱发重复消费。比如很多人第一次在 Windows 10 上装 RabbitMQ会遇到启动失败。最常见的原因是 Erlang 版本和 RabbitMQ 版本不匹配或者依赖的rabbitmq_management插件没有启用。启动失败会导致队列不可用生产者不停重试发送一旦服务恢复积压的消息和重试的消息混在一起就很容易出现重复。还有一个高频问题修改 RabbitMQ 服务端口。默认 5672 端口被占用时很多人只知道改 Web 管理页面的端口却遗漏了 AMQP 端口结果客户端连接还是走 5672撞上别的服务。改端口要记得修改rabbitmq.conf里的listeners.tcp.default并且同步检查防火墙。从运维角度我更建议保留默认端口通过防火墙白名单控制访问这样最省心。Linux 上部署 RabbitMQ 时还要注意内核参数和文件描述符限制默认的ulimit -n太小的话高并发下连接数很快打满消费者和 broker 之间出现连接闪断也会触发消息批量重投。5. 常见问题速查表与排查思路5.1 快速判断一条消息是否真的重复排查重复消费问题时第一步不是看代码而是先确认“是不是真的重复了”。我见过不少团队把“业务里同一个操作被执行了两次”误判成“消息重复消费”但实际是两个不同的请求触发了同一个逻辑。判断方法很简单去看消息日志里有没有两条相同的messageId或者相同的业务幂等键。如果在 RabbitMQ 的管理后台里能看到同一条消息被投递了多次那才是真正的重复消费如果每次进来的消息 ID 都不同那问题可能出在上游接口被重复调用。另一条思路是看消费者日志。如果消费者已经做了去重处理重复消息会留下“去重拦截”之类的日志。没有这类日志说明去重代码可能没生效或者幂等键选错了。我最常发现的问题就是幂等键选成了“当前时间戳”每次重投都会生成不同的值去重自然失效。5.2 排查清单与应急处理下面是一份我从实际经验中总结的排查清单遇到线上重复消息告警时可以按照这个顺序来。确认重复范围是单条消息重复还是某个队列的一批消息重复是消费者重启后出现的还是一直存在。查看消费者日志中的消息 ID对比重复消息的属性和业务幂等键是否相同。检查 ack 模式确认是否开启了自动 ack开启自动 ack 的话立刻改为手动 ack。检查消费者重试策略看是不是无限重试是的话改成有限重试并配置死信队列。检查生产端发布确认确认消息发送是否有 confirm重试时有没有复用同一个 messageId。检查业务层的幂等键选择确认幂等键是否为业务稳定字段。检查数据库唯一约束确认业务表是否加了唯一索引是否捕获了唯一键冲突异常。检查 Redis 去重 key 的过期时间评估是否短于重复消息可能出现的最大间隔。检查死信重投逻辑确认重投前是否判断了重投次数避免无限循环。急性问题处理上最快速的止血手段是先把消费者停掉清理掉积压消息再修复代码重新部署。不要一边让有问题的消费者继续跑一边修代码那样只会让垃圾数据越来越多。如果重复数据已经进入了数据库要先评估影响面能通过 SQL 修复的尽快修复不能修复的就人工核对别急着删数据。这些排查步骤看起来琐碎但每一条背后都对应着一次线上事故。建议你把这份清单贴到团队文档里下次再遇到同类问题至少能省一晚上的排查时间。6. 一些掏心窝的经验最后分享几条我在实战中总结出来的小经验。第一幂等设计一定要在系统设计阶段就进入等重复数据上线之后再补成本会翻好几倍。我在新项目启动时会直接要求所有 MQ 消费者都要提供自己的幂等方案不然不允许上线。第二数据库唯一约束是我最偏爱的兜底手段因为它不依赖外部中间件数据库本身不会“丢记录”。即使你已经用了 Redis 去重我也建议在落库的表上加一个唯一索引反正多一层防线不亏。第三处理重复消息时日志一定要打全。每次拦截重复消息都要记录完整的消息 ID 、幂等键、消费者的实例标识。不然等到线上出问题你想证明“这条消息确实被拦截了”都拿不出证据。第四RabbitMQ 的管理后台是排查重复消费的好帮手里面可以看到 queue 的deliver计数和ack计数如果deliver数量明显大于生产端发送的数量基本就能确认重复投递了。这些经验都是真金白银换来的。希望你读完这篇文章后不用像我一样非得在凌晨两点被一个重复订单炸醒才想起去给消费者写幂等。