消息中间件出问题，最怕的不是慢，而是消费者明明处理完了业务，结果又收到同一条消息；更怕的是日志里查不到这条消息，钱已经扣了。我在负责某订单系统的消息链路时，这两类问题都遇到过：重复消费导致订单状态从“已支付”被回退成“待支付”，消息丢失导致一笔入库记录整整缺了三天。很多人第一反应是RocketMQ不行，但排查到最后，绝大多数问题都出在使用姿势上。这篇内容就把重复消费和消息丢失这两件事从头到尾拆开讲，包括根因、排查思路、修复方案和监控兜底，适合正在用RocketMQ做核心业务消息的开发和运维参考。
1. 先说结论：RocketMQ的投递语义决定了重复无法根除
1.1 “至少一次”意味着什么
RocketMQ默认的消费语义是At Least Once，也就是每条消息至少被投递一次。这不是bug，而是分布式系统里的一个基本取舍。网络会抖动、客户端会超时、服务端会重试，只要消息在传输过程中没有收到确认，生产者就会重新发送，消费者可能会在提交位点之前崩溃，重启后又会从旧的位点重新拉取。只要有一方不确定消息是否真的处理成功，就会选择再投一次，避免消息彻底丢掉。
这一点必须理解透：重复消费不是RocketMQ的缺陷，而是它在“不丢消息”前提下必然付出的代价。如果RocketMQ改成Exactly Once，那它就必须在事务、幂等、状态持久化上付出巨大成本，而且很多业务场景根本不需要这种强语义。所以正确的目标不是消灭重复，而是让重复的消息在业务层面“看起来只发生了一次”。
1.2 重复消费到底从哪里来
我把线上遇到的重复消费来源分成三类，排查时要逐一排除：
生产和网络重试导致的消息重复发送。生产者调用send方法后，没有收到服务端的返回，于是触发重试。实际上Broker可能已经写盘成功了，但响应在网络中丢失了。这时重试发送的同一条业务消息，会以新的MessageId写入队列，消费者看到的就是两条一模一样的消息。
Broker端的重新投递。当消费端在消息处理完成后、提交消费位点之前发生宕机或网络断开，Broker会认为这条消息没有被消费，于是再次投递给同一消费者组里的其他消费者，或者在该消费者恢复后重新推送。
消费者自身逻辑造成的重复。例如消费超时引起的重投、线程池并发消费时多个线程同时拿到同一批消息、手动提交位点失败后重启重拉等。这类重复往往与业务负载、消费超时配置密切相关。
这三类重复的最终表现是一样的：业务方法被调用了两次。但只要在消费逻辑里做了幂等保护，就不会产生脏数据。
1.3 为什么不能只依赖RocketMQ的MessageId去重
RocketMQ的消息有系统生成的MessageId和业务自定义的Key。很多团队直接把MessageId作为去重键，存在一张去重表里，看起来简单，实则不靠谱。同一个业务操作可能因为生产者重试而被编成不同的MessageId；同一个消息在一次正常投递和一次延迟重试时虽然MessageId一致，但业务语义上可能已经不再代表同一笔操作。
更合理的做法是让业务消息本身携带全局唯一的业务标识，比如订单号、流水号、支付单号。这个标识必须是业务层面的唯一键，并且能映射到具体的业务操作。幂等判断时，优先使用这个业务唯一键，MessageId只能作为辅助的兜底参考。
2. 消息丢失的三个环节与缺口分析
2.1 生产端丢消息：发送方式与重试机制的真实坑
生产端发送消息有三种方式：同步发送、异步发送和单向发送。
单向发送只负责把消息发出去，不关心结果，也不做任何重试。这种场景只适合日志流水这类丢了也无所谓的消息，用在订单、支付上就是灾难。异步发送如果回调处理不当，也容易出现静默失败。最常见的问题是没有在回调里处理异常，或者把异常吞掉了，等发现时消息早就断流了。
我见过一个事故：异步发送消息时，线程池满了，send方法直接抛异常，但外层代码没有捕获，消息既没有补偿也没写本地日志，后续链路全部中断。RocketMQ生产端的重试机制默认在同步发送时生效，可以设置retryTimesWhenSendFailed来控制。但重试只在未收到响应的情况下有意义，如果Broker已经写盘成功只是应答丢失，重试会产生重复消息而不是丢失。
在核心业务中，推荐使用同步发送，并对发送结果做三级兜底：
- 发送失败时，直接把消息写入本地消息表；
- 本地消息表通过定时任务扫描重发；
- 重发多次仍失败，触发告警人工介入。
这是最稳妥的方式，虽然多了一张表，但能保证消息不会在生产端静默消失。异步发送不是不能用，而是必须保证回调里有完善的异常记录和补偿入口。
2.2 Broker端丢消息：刷盘策略与主从复制的不一致窗口
Broker端消息丢失主要出在两个地方：内存消息没刷盘就宕机、主从复制还没完成时主机就挂掉。
RocketMQ的存储模型是顺序写文件，生产环境建议开启SYNC_FLUSH，也就是同步刷盘。每条消息写入内存后，要等数据落盘才返回写入成功。这个策略会牺牲一部分吞吐，但对金融、交易类系统来说是必须的。如果使用ASYNC_FLUSH，在极端情况下，操作系统还没把页缓存刷到磁盘上，进程就崩了，数据就丢了。
更隐蔽的是主从模式。如果主节点写入成功并返回给生产者，但数据还没来得及同步给从节点，主节点宕机后从节点被切换为主，这段时间内的消息就丢了。需要将Broker的brokerRole设为SYNC_MASTER，并配合SYNC_FLUSH，让消息在主从都落盘后再向生产者确认。这样虽然单条消息的延迟会增加，但换来的是更高的可靠性。
我见过一个小团队，为了压测性能把刷盘设为ASYNC_FLUSH，主从也设为异步复制，结果线上一次断电导致大量消息丢失。如果你真的需要极致性能，可以接受偶尔丢失，那另说；但只要业务数据涉及资金、库存、状态变更，就别在这两个参数上省。
Broker端还有一个容易被忽略的坑：磁盘写满时消息写入会直接失败。RocketMQ的commitlog文件按固定大小预分配，如果磁盘剩余空间不足，文件写不进去，消息就丢了。需要监控磁盘使用率，以及commitlog目录的inode。
2.3 消费端丢消息：位点提交是最大的暗坑
消费端丢消息最典型的场景是：业务处理完成之后，还没来得及提交消费位点，进程就被kill了。重启后，消费位点回退到之前的位置，那条消息会重新投递。这一般只会导致重复，不会导致丢失。
真正导致丢失的是另一种情况：消费端在处理消息时抛异常，但没有捕获，也没有重试，而是直接提交了位点。还有更隐蔽的，使用CONSUME_SUCCESS状态返回，但实际业务逻辑已经走了catch分支，把错误吞掉了。这条消息被标记为消费成功，但实际上业务没做，这就是一种“伪成功”的消息丢失。
RocketMQ的消费位点存储在Broker端，消费者本地也会维护一个快照。当重平衡发生时，如果消费者没有主动提交位点，可能从旧位点重新拉取，也可能从新位点开始，取决于ConsumeFromWhere配置。为了避免丢消息，建议设置CONSUME_FROM_LAST_OFFSET只应用于新创建的消费组，老消费组不要随便改，否则会直接跳过未消费的消息。
另外，手动提交位点时要谨慎。很多客户端支持异步提交commitAsync，如果应用在提交完成前就退出了，位点可能没提交成功。想保证不丢，就用同步提交，或者在异步提交的监听回调里处理失败重试。每一条消息处理完后都提交位点会造成性能问题，通常还是按批提交，但批次大小要合理，不要等太大。
2.4 从一条“三天后才发现缺失”的日志反推丢失点
我处理过的一个实际案例：某账户余额变更消息在D1天发送，但直到D4天对账才发现D1天少了一笔变更记录。排查过程是这样的：
先看生产端日志，send返回成功，说明消息已经提交给Broker。再看Broker的commitlog，文件里确实有这条消息，说明Broker持久化没丢。接着看消费端，发现消费组当前位点已经远超这条消息的偏移量，说明消费者没有拉取这条消息。最后查消费端的重试队列，发现这条消息在消费时抛了异常，进入了重试主题。
诡异的是，重试队列里这条消息已经不在了。查了重试次数，发现重试次数被设置成了0，意味着第一次消费失败后没有进入重试流程，直接按成功处理了。翻代码才发现，异常处理逻辑里有一段catch (Throwable t) { return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }，把任何异常都当成了成功。这是极其危险的写法，也是消费端丢消息最常见的源头。
修复方案很简单：捕获到异常后，返回RECONSUME_LATER，让消息进入重试队列。同时，修正全局位点监控，加一条“消费成功但业务处理时间异常短”的告警，就能及时发现问题。
3. 重复消费的排查链路与幂等设计实践
3.1 从业务日志反查重复消费的完整思路
发现重复消费时，先去业务应用里找到那条异常记录，看它的处理日志和时间戳。如果同一条业务唯一键在日志里出现了两次，且两次的时间间隔很短，多半是生产端重试导致的重复。如果两次间隔很长，甚至跨越了分钟级，那通常是消费位点回退或者重投导致的延迟重复。
还有一类重复是并发重复。消费者组里多个消费者同时处理一批消息，某个消费者的处理超时，Broker把消息重新投递给另一个消费者，两个消费者同时处理同一条业务数据。这种情况下，日志时间非常接近，甚至在同一秒。
排查时要重点看这几个地方：
- 消息的生产者日志，确认是否发生了发送重试及重试次数；
- Broker侧查看该消息的投递记录和消息轨迹，RocketMQ通过
mqadmin或消息轨迹功能可以看到消息的完整流转； - 消费者应用自身的线程名、进程ID、重平衡日志，确认是否存在并发处理同一消息的情况。
我把消息轨迹功能视为排查这类问题的第一利器。开启它之后，每条消息的发送时间、写入Broker时间、投递给消费者时间、消费结果、重试次数都一目了然。可以在RocketMQ的配置文件里打开traceTopicEnable=true，让消息轨迹先于业务结果记录到轨迹主题中。
3.2 幂等方案选型对比：去重表、唯一键约束、分布式锁和状态机
重复消息不可怕，可怕的是没有幂等保护。下面几种方案我都在线上用过，各有适用场景：
数据库唯一键约束。适合新增类操作。比如订单创建接口，在订单表上建一个唯一索引，字段是biz_unique_key，这个键是业务产生的全局唯一标识。重复消息第二次插入时，数据库报duplicate key异常，捕获后直接当成已处理即可。这种做法最简单，性能也不错，但要防止把其他唯一冲突也误当重复。
去重表方案。在消费逻辑开始时，先把业务唯一键插入一张去重表。插入成功才继续处理，插入失败说明消息已经处理过了，可以直接跳过。这张表要和业务数据在同一个数据库事务里写入，才能保证一致性。去重表需要定期清理，否则会膨胀。
分布式锁方案。用Redis或数据库锁保证同一时刻只有一个线程能处理同一个业务键。这个方案能解决并发重复，但如果是不同时间点的多次投递，锁释放后还是会被重复处理。分布式锁只能作为辅助，不能单独充当幂等方案。
状态机校验方案。业务数据本身有状态流转。比如订单状态从“待支付”到“已支付”是一个不可逆的过程。如果收到一条提款消息发现订单已经是“已支付”，说明这条消息要么是重复的，要么逻辑有问题。这种方案依赖业务模型的规范程度，适合状态明确的场景。
我的建议是：数据库唯一键约束 + 去重表 + 状态机校验组合使用，分布式锁作为并发控制。在关键链路上，多一道校验不亏。
3.3 唯一标识设计：从MessageId升级到业务操作幂等键
设计消息结构时，很多人直接放一个JSON的body，没有显式定义唯一键。消费端拿到消息后，只能通过body内容里的业务字段来判断。一旦body字段设计得不够严密，重复消息就难以识别。
我的做法是在消息头或者消息体里显式加一个bizUniqueKey字段，统一命名规范。这个字段的值由生产端生成，可以是UUID，但更推荐使用业务语义强的组合键，比如orderId + operationType + timeStamp。如果同一笔业务操作允许重复发送，那么bizUniqueKey必须保证唯一。
在消费端，把整个幂等判断抽象成一个公共组件：
- 从消息中解析出bizUniqueKey；
- 本地数据库查询该键的处理记录；
- 存在则返回成功；
- 不存在则在业务事务里插入记录并执行业务逻辑；
- 事务提交后删除“处理记录”并根据清理策略保留必要时间。
这里的核心是“插入记录”和“执行业务”必须在同一个事务里，否则可能出现记录插入了但业务没执行，或者业务执行了但记录没插入的尴尬情况。
4. 事务消息与最终一致：既能防丢也能防错乱
4.1 事务消息为什么适合发货扣款这类场景
RocketMQ的事务消息解决的是“本地数据库操作和发送消息的原子性”问题。传统做法里，先更新数据库再发消息，如果消息发送失败，数据库已经改了，两边不一致；先发消息再更新数据库，如果数据库更新失败，消费者已经拿到消息开始消费了。
事务消息的思路是：先发送一条半消息，消息暂时不可被消费者消费；然后执行本地事务；本地事务成功后，向Broker提交确认，消息变为可消费；如果本地事务失败，回滚消息。如果Broker在等待确认时没有收到结果，会回调生产端的checkLocalTransaction方法，询问本地事务最终状态。
在订单和账户系统中，使用事务消息可以既保证本地事务成功则消息必然发出，又保证本地事务失败则消息被丢弃，从源头避免了消息丢失和消息错发的矛盾。
4.2 半消息状态的处理与回调接口的正确实现
实现事务消息时，TransactionListener有两个方法：executeLocalTransaction和checkLocalTransaction。
executeLocalTransaction在消息发送后执行本地事务。这里最容易犯的错是：本地事务执行完成后，返回到commit状态，但此时如果网络抖动导致这条commit没能送回Broker，Broker就会认为是“消息状态未知”，进而触发check回调。所以checkLocalTransaction必须能够查到本地事务的最终结果。
我的做法是在本地事务表里维护一条记录，包含事务ID、业务数据、状态。状态有BEGIN、SUCCESS、FAILED三种。executeLocalTransaction执行完本地事务后就更新状态。checkLocalTransaction只查这个表，根据表里的状态返回COMMIT或ROLLBACK。
这里特别要注意的是，本地事务表要和业务表在同一个连接上执行。比如使用某个数据源时，必须保证事务消息的本地事务和业务表更新在同一个数据库事务里。否则check回调可能查到不一致的状态。
还要防止同一个事务消息被误认为是普通消息。有的团队用了事务消息，但还是用普通消费者直接消费，结果在半消息阶段就被消费了，造成脏数据。RocketMQ的事务半消息在commit之前，默认不会对消费者可见。
4.3 本地消息表与消息状态对账的兜底方案
事务消息虽然强，但遇到极端情况，比如本地事务表记录了SUCCESS，但commit通知在发送过程中因网络故障一直没送达，会导致消息一直处于半消息状态，消费者永远看不到。对于已经完成的本地事务，这条消息就相当于丢了。
因此，仅靠事务消息还不够，我额外加了一个对账任务。这个任务每隔几分钟扫描本地事务表，找到那些状态为SUCCESS但对应的消息没有出现在消息队列中的记录，主动向Broker查询数学消息状态，再根据状态决定是触发check还是重新提交消息。
另一种更简单的兜底方案是本地消息表 + 定时重发。不依赖RocketMQ事务消息，而是把业务表和消息表放在同一事务里提交，然后由定时任务扫描消息表把待发送的消息发到RocketMQ，发送成功后标记状态。这个方案没有分布式事务那么优雅，但逻辑极其清晰，很多老系统还在用。
如果你既想用事务消息，又不想搞复杂的本地事务表，那建议至少在本地记录发送流水，并把流水表的写入和业务表写入放在同一个事务里。这个流水表就是消息的“小票”，将来无论排查重复、丢失，还是做补偿对账，都靠它。
5. 可靠性压测与线上监控的实操要点
5.1 用真实流量回放测试重复与丢失概率
上线前做可靠性压测，不能只测吞吐量。我用过一个比较简单有效的方法：把真实业务环境中的消息流量录制下来，回放到测试集群，同时在消费端故意制造一些故障场景，比如杀掉消费者进程、让Broker磁盘写满、网络随机抖动，观察消息是否有重复或丢失。
压测时重点看几个指标：
- 是否存在漏消费：用对账程序比对生产端发送记录和消费端成功记录；
- 是否存在重复消费：看消费端日志里业务唯一键的重复次数；
- 消费端重试次数分布：高重试次数是否集中在某个topic或某个消费者消费者；
- 消费位点滞后：是否在峰值后恢复。
压测的结论不能只看“平均时长”，要看极端情况下是否出现消息丢失。如果一次故障演练就发现丢消息，那就是配置有问题，必须找到具体环节修复后再测。
5.2 监控消费位点与lag的告警
线上监控里，消费位点和消费者的lag是最直接的健康指标。lag大于多少算异常，不能拍脑袋定，要根据业务容忍度。一个实时订单系统，lag超过几百毫秒就应该报警；一个数据分析系统，lag超过几十分钟可能还能接受。
我推荐的指标是消费位点的变化率对比生产速率。只有在lag持续增长时才有问题。瞬时尖峰不用管，但要加一条“lag在5分钟内持续增长”的告警规则。
另一个监控点位是消息的重试队列深度。如果重试队列持续有消息堆积，说明某个消费者逻辑存在bug或者下游依赖变慢。重试次数超过阈值会进入死信队列（DLQ）。DLQ有消息时，必须立刻告警，因为这意味着有业务操作多次重试都失败了，发生了实质性的处理失败，需要人工介入。
对于生产者，也要监控发送失败次数和发送响应耗时。发送失败率升高往往是Broker不稳定或磁盘瓶颈的信号。我遇到过磁盘IO被打满导致发送超时，如果没有这个告警，消息可能因为重试失败而全部堆积在生产者本地。
5.3 端到端对账机制：一个定时任务兜住所有漏洞
无论前面的配置多么完美，都有可能出现意外。所以端到端对账是可靠性防线上的最后一环，必须做。
对账的思路很简单：生产端维护一张发送流水表，消费端维护一张消费流水表。定时任务把两边的数据进行比对，找出长时间未发送成功的消息、长时间未消费的消息、以及重复消费次数异常的消息。
具体实现：发送流水表包含业务唯一键、消息ID、发送时间、发送状态。消费流水表包含业务唯一键、消息ID、消费时间、消费状态。定时任务比如每分钟或每五分钟跑一次，关联生产端和消费端，按业务唯一键比对。如果某一方缺失，说明这里存在丢失或重复。
如果你的系统规模不大，可以不用专门建两张表，直接在日志里把业务唯一键打到日志，对账工具从日志中提取。但既然都要做消息中间件了，业务数据量一定不会太小，我建议还是规范化落两张表，对账SQL越简单越好。
对账任务本身要幂等，防止它自己重复跑产生误告警。还要支持手工补偿消息的重新发送，这样发现问题后，可以一键重派未消费的消息。
6. 最后的实操建议与避坑清单
6.1 消费端每次升级前先确认这五个配置
RocketMQ消费者有很多配置项，绝大多数默认值都能跑，但可靠性相关的一定要人工确认：
consumeThreadMin和consumeThreadMax：线程数会不会导致并发重复；consumeTimeout：消息处理超时时间，超时会触发重投；messageModel：是集群模式还是广播模式，广播模式下每个消费者都会收到消息，不存在分派，重复概率更高；maxReconsumeTimes：重试次数上限，默认15次，可以按业务调整；consumeFromWhere：新消费组从哪里开始消费，老消费组千万别乱动。
这里最容易踩的坑是consumeThreadMax设得过高，业务处理没有做并发控制，导致同一个订单的消息被两个线程同时处理。在线程池模型下，消息分配是并发拉取，一个消费者可能同时消费同一批消息，所以一定要在业务层做好幂等。
6.2 老团队踩过的三个“低级错误”
我见过太多因为几个低级错误引发的线上事故，在这里列一下，希望后面的人别再踩：
第一个：消费回调里吞掉异常返回SUCCESS。不管什么异常，一律在catch里返回CONSUME_SUCCESS，结果业务数据错乱，还找不到原因。正确做法是：可重试的异常返回RECONSUME_LATER，不可重试的异常记录日志后也要返回RECONSUME_LATER，让消息进入死信队列托底。
第二个：发送消息用单向发送，认为“只要不崩溃就不会丢”。网络瞬断、超时、Broker重启，都可能让消息在发送时悄无声息地消失。单发只适合日志等非关键数据。
第三个：对账表格里没有业务唯一键。两张流水表只有MessageId，没有业务唯一键，重复消息和丢失消息根本比对不出来，等到发现的时候已经过了很久。设计流水表一定要把业务唯一键放进主索引。
6.3 如果只能记住三件事
一个是：重复消费靠业务幂等解决，别指望RocketMQ帮你根治；一个是：消息丢失的防护要贯穿生产、Broker、消费三个环节，任何一个环节放松都可能丢消息；还有一个：一定要有端到端对账机制，这是最后一道防线，没有对账的可靠性都是纸上谈兵。
我个人的习惯是把对账和监控放在压测之后、发布之前，先用故障演练验证一遍。只有真刀真枪杀掉Broker进程、断掉网络，才能确认你的配置是否真的可靠。RocketMQ本身已经提供了非常成熟的可靠性能力，但只要用错了，再强的能力也救不了业务数据。希望大家在遇到重复消费和消息丢失时，先冷静定位是哪个环节、哪个配置、哪个逻辑出了问题，再对症下药。
