RocketMQ消息重复消费七个根源：从源码到幂等实战

先抛一个我印象特别深的现场：凌晨一点，业务群炸了，说订单重复创建，系统里出现两条一模一样的订单数据。负责的同事一顿排查，最后定位到 RocketMQ 消费者把同一条消息处理了两遍。紧接着群里有人来了一句“加个幂等不就好了”，这话没毛病，但也直接终结了这次技术讨论。说实话，每次遇到“消息重复消费”，如果只是停留在“加幂等”这个层面，那下一次换一个场景，你还是会踩坑。我花了一整晚把 RocketMQ 的源码翻了一遍，把消息从生产端投递到消费端确认的完整链路梳理出来，发现重复消费这件事，至少藏着 7 个触发源头，每一个都有对应的源码逻辑在支撑。

这篇文章适合谁？不是只看过 RocketMQ demo 的新手，而是那些已经在用 RocketMQ，并且被“消息丢失、消息重复、消费乱序”折磨过的后端开发。我会把这 7 个根源从源码层面拆开，每一个都讲清楚触发场景、源码位置和防守思路。看完之后你至少能做到：线上再有人告诉你“消息重复了”，你脑子里能立刻浮现出三个以上的怀疑对象，并且知道下一步去翻哪段日志、看哪个 offset。

1. 先把问题说清楚：RocketMQ 的投递语义到底是怎么定义的

1.1 什么是消息重复消费

先给一个大家都认可的定义：所谓消息重复消费，是指同一条业务消息，在消费者这里被“处理成功”了不止一次。

这里我把“处理成功”加了引号，是有原因的。很多人在排查重复消费时，会把“收到消息”和“处理消息”混为一谈。比如一条订单消息，消费者从 broker 拉下来了，业务逻辑执行到一半，数据库事务回滚了，然后消费者重新拉取这条消息再执行一次。请问这算不算重复消费？严格说，这不叫重复消费，这叫“消费失败重试”，是消息队列本来就该做的事。真正危险的是另一种情况：业务逻辑确实成功执行了，事务也提交了，但因为某种原因，消息队列认为“你没消费成功”，于是又把同一份消息投递过来了。这时候，你的订单被创建了两次，你的短信被发送了两条，你的积分被累计了两倍。

所以，聊重复消费，本质是在聊“消息队列的判断依据”和“真实业务执行结果”之间出现了裂缝。

1.2 RocketMQ 选的是哪条路

整个消息队列生态里，关于消息投递语义，基本就三档：at most once（最多一次）、at least once（至少一次）、exactly once（恰好一次，通常需要配合业务幂等才能达成）。

各种 MQ 为了避免复杂的分布式事务，普遍的选择都是 at least once，RocketMQ 也不例外。RocketMQ 官方文档其实早就写明了：消息可能重复，应用方需要自行保证幂等。这句话被很多人当成“免责声明”扫一眼就过去了，但它背后的含义是：只要你在用 RocketMQ，重复消费从整个系统的概率上讲是必然事件，不是偶然事件。

再往深一层，RocketMQ 为什么做不到 exactly once？我在看源码的时候越来越确认，这本质上不是 RocketMQ 单点能做到的——生产端可能重复写、broker 端可能重复存、消费端可能重复拉，每一环都没有一个全局统一的事务视图。既然做不到“天然去重”，那搞清楚哪些环节会造成重复，就成了唯一靠谱的路径。

2. 生产端三个根源：还没进 broker，消息就已经被复制了

很多人排查重复消费，第一反应都是去消费端看代码，但我要先提醒一句：源头可能在生产端。如果消息在进入 broker 之前就已经被写了两份，那消费端不管怎么做，收到的都是重复的。

2.1 根源一：生产者发送重试，同一条消息被投递了多次

先看生产端最常见的代码，RocketMQ 自带的同步发送示例：

java复制DefaultMQProducer producer = new DefaultMQProducer("order_producer_group");
producer.setNamesrvAddr("127.0.0.1:9876");
producer.start();

Message msg = new Message("ORDER_TOPIC", "TAG_A", "ORDER_12345".getBytes(StandardCharsets.UTF_8));
SendResult result = producer.send(msg);
System.out.println(result.getMsgId());

这套代码看似简单，但内部在 DefaultMQProducerImpl 的 sendDefaultImpl / sendKernelImpl 方法里，藏了一个默认行为：发送失败自动重试。

RocketMQ 默认的发送超时时间是 3000ms，默认重试次数是 2 次。当 producer.send(msg) 抛出一个 RemotingTooMuchRequestException，或者由于网络抖动没有收到 SendResult 应答时，客户端会重新走一遍发送逻辑。整个过程在 DefaultMQProducerImpl.sendDefaultImpl 的 for 循环里：

java复制for (int i = 0; i < retryTimesWhenSendFailed; i++) {
    // 选择一个当前可用的 broker
    MessageQueue mq = ...;
    try {
        return sendKernelImpl(msg, mq, ...);
    } catch (RemotingException e) {
        // 网络异常，选下一个 messageQueue 重试
        continue;
    } catch (MQBrokerException e) {
        // broker 明确返回错误，重试
        continue;
    }
}

这里的关键在于：sendKernelImpl 一旦把消息发给 broker，并且 broker 收到并写盘了，但网络超时导致客户端一直没有收到 SendResult，此时客户端会认为发送失败，于是进入下一次循环，把同一条 Message 再发一次。第二次发送时，broker 会重新生成一个新的 msgId，并且写入一个新的 offset。从 broker 视角看，这是两条消息；从业务视角看，它们是同一条业务消息的重复投递。

注意：RocketMQ 的 msgId 是 broker 端生成的，不是业务消息体里的唯一键。如果业务侧没有给消息设置自己的唯一业务 ID，后面做幂等就非常被动。

所以根源一的本质是：网络超时 + 生产端自动重试，导致同一条业务的原始消息被写入 broker 多次。

2.2 根源二：broker 写入成功，但响应超时/响应丢失

这一条和生产端重试是伴生关系，但它的触发点已经延伸到 broker 侧了。

SendMessageProcessor.processRequest 是 broker 处理消息写入的入口。当消息进来之后，会调用 handlePutMessage，然后把写入结果封装成 RemotingCommand response，通过 NettyChannelHandlerContext 写回客户端。但网络层是不可靠的，可能出现这几种情况：

• 客户端设置的超时时间太短，broker 还卡在刷盘/写入索引的时候，客户端已经等不及抛出超时。
• 服务端把 response 写回 Netty 通道，但中间连接被断开或者读写缓冲区异常，客户端没有收到。
• 服务端 GC 停顿导致 response 延迟，客户端在 ResponseFuture 上等不到结果。

无论哪一种，最终表现都一样：broker 上其实已经有了这条消息，消费者随时可以拉取到，但生产者以为自己发送失败了，于是又走了一遍“根源一”的重试路径，又写了一模一样的消息内容。

我在源码里注意到一个细节，SendResult 里会返回 offsetId 和 msgId，这套信息是给运维和排查用的。但如果生产端没有把这次返回的 msgId 持久化到日志，或者日志被冲掉了，再想从这条链路定位重复就很难。

2.3 根源三：刷盘超时/同步复制超时，broker 变成“假失败”

这一条在普通开发者那里讨论得不多，但我觉得是理解 RocketMQ 高可用设计非常关键的一环。

RocketMQ 消息写入 CommitLog 后，并不是立刻就算成功。如果 Broker 配置的刷盘方式是 SYNC_FLUSH，那么必须等消息真正落到物理磁盘上，才会返回给生产端成功。如果配置的主从同步方式是 SYNC_MASTER，那么还要等消息复制到 slave 并确认之后才会返回成功。

相关代码集中在 CommitLog 的写入路径和 GroupCommitService 中。当刷盘超时或同步复制超时，handlePutMessage 会返回 PutMessageStatus.FLUSH_DISK_TIMEOUT 或 PutMessageStatus.FLUSH_SLAVE_TIMEOUT，最终发送给生产端的响应里，code 是 SendMessageProcessor 根据状态码转换的失败 code。

但这里有一个非常尴尬的事实：消息其实很可能已经写进 CommitLog 了，只是确认机制太严格，超时给你报了个失败。生产端拿到失败 code 之后，理所当然地触发重试，于是同一条消息又被投递了一遍。如果你用的是同步发送 + 默认重试，这一条会跟根源一、根源二叠加出现，重复的概率显著上升。

实操心得：调 SYNC_FLUSH 和 SYNC_MASTER 这类可靠性参数时，一定要同时评估生产端的超时时间和重试策略。我见过不少团队，一边把 broker 可靠性拉到最高，一边生产端超时时间设置成 1 秒，结果就是刷盘稍微慢一点，生产端立刻重试，消息重复率飙升。可靠性参数不能单看 broker 侧，要和客户端侧的等待时长配合。

到这里你发现了，生产端三个根源可以归纳为同一句话：网络不确定性 + 自动重试，让“一条业务消息”在物理上变成了“多条存储消息”。也就是说，哪怕消费端一丁点问题都没有，只要生产端重复投递，重复消费就已经注定发生。

3. 消费端四个根源：消息只消费一次，但 offset 没跟上

如果生产端只投递了一份消息，消费端还会不会重复？答案是会。根源都在消费位置 offset 上。RocketMQ 的消费进度靠 offset 记录，“这个 offset 之前都处理完了”是消费者的核心判断依据。只要 offset 的提交比业务成功晚了一步，或者因为某种异常根本没提交，重复消费就会立刻出现。

3.1 根源四：消费线程耗时过长，触发系统重投

先引一个 RocketMQ 的默认参数：consumeTimeout，默认值是 15 分钟。在 DefaultMQPushConsumer 初始化时，这个值会传给底层的 ConsumeMessageConcurrentlyService / ConsumeMessageOrderlyService。消费线程处理一条消息超过了这个时间，broker 侧的消费进度管理机制会把这条消息判定为“消费超时”，然后自动重新投递。

这个机制的源码位置在消费者向 broker 发送心跳和消费进度时体现得比较隐蔽。实际上，DefaultMQPushConsumerImpl 的 start 方法里有一个定时任务，会定期扫描处理中的消息。一旦超过 consumeTimeout，消费者端的 MessageListenerConcurrently 会收到 RECONSUME_LATER 状态，然后消息会走 sendMessageBack 回到 broker 的重试队列。

这里有一个非常值得警惕的场景：你的业务逻辑在数据库里执行得很慢，比如一条消息要调外部接口、做复杂计算，超过了 15 分钟。但就在第 16 分钟的时候，数据库事务提交了，业务其实成功了。偏偏消费者框架已经等不及了，直接把这条消息标记为超时，请求重投。于是下一条同内容消息再次进来，原本幂等的逻辑如果没有做，重复处理就是板上钉钉的事。

注意：15 分钟是默认值，不是说你可以依赖这个值。真实生产环境里，消费一条消息超过几分钟就已经算异常了。我建议把 consumeTimeout 调小一点，比如 5 分钟，宁可系统早点暴露问题，也不要让一条慢消息卡住整个队列的语义。

3.2 根源五：业务事务提交成功，但 offset 提交失败

这是最典型的重复消费场景，也是“分布式事务一致性”这个老问题的具体体现。

RocketMQ 并发消费的核心类 ConsumeMessageConcurrentlyService 的 processConsumeResult 方法决定了 offset 怎么提交。默认情况下，MessageListenerConcurrently 返回 CONSUME_SUCCESS 时，消费者才会向 broker 提交这个偏移量。但这里的问题是：业务代码的执行结果和 offset 的提交是两个独立动作，它们不在同一个本地事务里。

看一个非常常见的代码：

java复制consumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
    for (MessageExt msg : msgs) {
        Order order = JSON.parseObject(msg.getBody(), Order.class);
        orderService.createOrder(order); // 数据库事务已提交
    }
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});

这段代码在绝大多数情况下没问题，但一旦 orderService.createOrder 执行完之后、消费者框架还没来得及提交 offset，进程发生了以下任何一种情况，你就完蛋了：

• 应用服务器突然断电，进程被杀。
• 消费者进行 rebalance，当前 MessageQueue 的消费线程被挂起，offset 没有持久化。
• 消费者所在 JVM 发生长时间 Full GC，Netty 事件线程卡死，导致发送 offset 更新请求失败。

结果就是：broker 认为这条消息没有被消费成功，消息重新被投递，“订单创建”这个业务逻辑又被执行了一遍。

我在源码里仔细看了 processConsumeResult 逻辑，它提交 offset 使用的是 updateOffset + persist 的组合，整个过程是异步的。也就是说业务返回 CONSUME_SUCCESS 之后，消息也不会立刻从消费队列上“消失”，而是等本地 offset 更新再定期持久化或者上报给 broker。这一步的延迟窗口，就是重复消费的高发地带。

3.3 根源六：重平衡（Rebalance）导致 offset 被重置回滚

这是所有根源里最具隐蔽性的一条。

RocketMQConsumer 端的负载均衡逻辑在 RebalanceImpl 的 rebalanceByTopic 方法中。消费者实例启动、宕机、topic 队列数量变化等都会触发 rebalance。rebalance 本身是正常机制，问题在于 rebalance 过程中消费位点的交接很容易出错。

常见情况是这样的：一个消费者组有 3 个实例在消费某 topic 的 8 个队列。某一台实例因为发布重启，触发了一次 rebalance，原本分配在重启实例上的 queue 被重新分配给其他实例。这时候，broker 端的消费进度可能还停留在几个 offset 之前，因为客户端本地的 offset 还没来得及上报。新实例接管队列之后，会从 broker 端保存的 offset 开始重新拉取，那么从这个“落后位置”到上次实际处理位置之间的所有消息，都会被再次投递。

更隐蔽的是，RocketMQ 的默认 MessageModel 是 CLUSTERING，同一个消费组里的消息是有且仅有一个实例消费的。但 rebalance 发生的那一瞬间，由于 processQueue 的锁和 offset 快照更新机制存在时间差，会产生一个非常短暂的重叠窗口：旧实例还在处理最后一批消息，新实例已经开始拉取同一批消息。两边同时处理，重复消费的锅就背在 rebalance 身上了。

实操心得：在 processQueue 里 lock 再消费，并不能 100% 规避 rebalance 带来的重复。RocketMQ 只是尽量让当前处理中的消息在 rebalance 后不再继续消费（通过 ProcessQueue 的丢弃策略），但 offset 落后时从旧位点重新拉取这件事，机制上就是会发生的。

3.4 根源七：手动重置消费位点（Reset Offset）引发回溯消费

这个根源跟代码 bug 没关系，是操作层面的人为因素。

RocketMQ 提供了重置消费位点的能力，通常用于“消息重复但业务想重新处理一遍”，或者“消息丢了想从更早位置开始重新消费”的场景。运维控制台或者 AdminTool 执行 resetOffsetByTime 之后，整个消费者组的 offset 会被强制指到某个历史时间点，消费者立刻从那个位置开始重新拉消息。

这里的隐患在于：重置位点是一个全局操作，它根本不关心哪些消息你其实已经处理成功了。只要 offset 往回拨，已经消费过、已经落库、已经发过短信的消息会统统再发一遍。这种“追溯式重复”往往规模巨大，也是最难用代码去防御的一种，因为它本质上是你自己强行让 MQ 忘掉了消费进度。

遇到这种情况，唯一有效的防线还是业务幂等：哪怕消息被回溯 10 万条，每一条的幂等键都能挡住重复写入。

4. 七个根源汇总 + 排查路径：从源码到日志，一步步定位元凶

4.1 七个根源速查表

为了方便大家直接拿去排查，我把七个根源的核心信息和特征整理成了一张表。

这张表我建议你直接收藏，下次遇到重复消费问题，逐条对照排查，比你自己瞎猜要快得多。

4.2 从日志定位重复消费来源

先提一个硬道理：排查重复消费，不能只盯着消费者代码，要把生产端日志、broker 日志、消费端日志三块拼在一起看。

第一步，确认消息是不是真的重复了，而不是误报。看消费者收到的 MessageExt，如果同一条业务消息有两个不同的 msgId，基本可以确定是生产端重复投递，重点关注根源一、二、三。如果 msgId 相同，说明同一条存储消息被重复拉取/投递了，重点关注根源四、五、六、七。

第二步，去 broker 上查这条消息的存储位置。如果是生产端重复投递，会在 CommitLog 里看到两条内容相同但 offset 不同的记录。如果是消费端重复处理，CommitLog 里只有一条记录。

第三步，看消费者的 offset 变化。通过 rocketmq-console 或者命令行查消费者组的 offsetStore，如果消费位点明显落后于实际处理位点，而且业务日志又显示消息处理成功，那就是根源五。配合 rebalance 日志和实例重启时间，基本可以判断是不是根源六。

第四步，检查是否有手动重置位点的操作记录。运维平台的工单系统或者控制台操作日志翻一翻，如果有 resetOffsetByTime 记录，根源七实锤。

实战技巧：生产端在发送消息时，务必给消息体里塞一个业务唯一键，比如 orderId 或 bizId，并且打印一条包含唯一键和 msgId 的发送日志。消费端在处理时，打印一条包含唯一键、msgId、当前 consumer 组和 queueId 的接收日志。这样一条消息从生产到消费的完整轨迹都是可追踪的，排查重复消费最多只花半小时。

5. 根治方案：把 at least once 变成业务上的 exactly once

七个根源分析完了，我知道你现在最想问的是：那怎么办？总不能让业务天天守着幂等吧。

我的答案很直接：只能让业务侧承担幂等，没有别的银弹。但幂等也不是只能硬着头皮加唯一索引，它是有设计套路的。

5.1 方案一：数据库唯一键（最推荐，几乎零侵入）

如果消费者最终是把数据写入关系型数据库，那顺手在业务表上建一个唯一键，用消息里的业务唯一键作为唯一值，是最朴素的方案。

sql复制CREATE TABLE `t_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_id` varchar(64) NOT NULL COMMENT '业务订单号，即幂等键',
  `user_id` bigint(20) NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_id` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

消费者代码里，insert 时捕获 DuplicateKeyException 然后直接返回 CONSUME_SUCCESS。这个方案的好处是：不依赖外部存储，和业务强一致，只要数据库事务提交成功，唯一键就生效，重复插入必然失败。坏处是：如果业务不是写数据库，而是调用外部 API、发消息、写文件，这个方案就用不了。

5.2 方案二：Redis 幂等（高性能，适合非数据库场景）

先 set 一个幂等键，设置合理的过期时间，比如消息处理的最长时限。只有当 setnx 返回 1 时才真正执行业务逻辑，否则直接 ack。

java复制String bizKey = "order:dedup:" + msg.getKeys();
Boolean firstTime = redisTemplate.opsForValue()
        .setIfAbsent(bizKey, "1", Duration.ofMinutes(5));
if (!Boolean.TRUE.equals(firstTime)) {
    // 说明已经处理过，直接确认
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
// 执行业务逻辑

注意几个坑：Redis 分片本身不是强一致的，如果遇到主从切换，幂等判断可能短暂失效；过期时间设置太短，长事务消息可能被重复处理；设置太长，Redis 内存浪费。所以这个方案适合“处理时间可控”的场景，不能无脑套用。

5.3 方案三：业务状态机 + 消息表（最严谨，适合复杂业务）

如果你所在团队对数据一致性要求非常高，我建议做一张独立的“消息幂等表”，把消费状态写进去，配合业务事务一起提交。

java复制@Transactional(rollbackFor = Exception.class)
public void handleOrderMessage(String bizId, String body) {
    MessageProcessRecord record = messageProcessRecordMapper
            .selectByBizIdForUpdate(bizId);
    if (record != null) {
        // 已处理过，直接返回
        return;
    }
    // 执行业务逻辑，创建订单
    orderService.createOrder(body);
    // 记录消息处理痕迹
    messageProcessRecordMapper.insert(new MessageProcessRecord(bizId));
}

关键点在于 selectByBizIdForUpdate 使用了悲观锁，锁住同一 bizId 的处理记录。同一个 bizId 第二次进来时，只有两种可能：要么事务已回滚，记录不存在的记录也不存在，继续处理；要么事务已提交，记录存在，直接跳过。“业务操作 + 记录消息处理痕迹”在同一个事务里提交，就保证了业务成功 = 幂等记录一定存在。这种做法在金融类、支付类系统里很常见。

个人经验：不要迷信某一种幂等方案能覆盖所有场景。核心思路是把“幂等标记”和“业务状态变更”放进同一个事务边界里，让两者同时成功或同时失败。上面三个方案我都用过，数据库唯一键最实用，Redis 最快，消息表加悲观锁最重但最稳。业务在哪个环境，就选哪个，没有万金油。

6. 最后分享一个现场复盘：压测时我亲手制造出来的 rebalance 重复消费

这篇源码分析是我在压测之后才开始动手写的，因为那次现场太典型了。借此复盘一下整体思路，也算是一个从“问题表象”到“源码定位”的完整案例。

6.1 事故现象和初步判断

压测环境，4 个消费者实例，消费一个 16 个队列的 topic。压测开始半小时后，数据库里出现大量重复订单。现象非常规律：重复出现的时间点正好是中间某两个消费者实例被自动扩容脚本重启的时间。我一开始怀疑是消费端代码问题，但消费逻辑非常简单，就是先查后插，理论上数据库主键能挡住。

后来翻了消费者日志，发现同一 bizId 在极短时间窗口内被两个不同的实例处理了。一个实例打印了“处理完成、事务已提交、offset 更新失败”的日志，另一个实例随后打印了“开始处理同一条消息”。这两个实例在同 5 秒内都参与了这个队列的消费。这就触发了根源六的典型特征：rebalance 期间，offset 交接出现重叠窗口。

6.2 源码定位和解决过程

我直接打开 RebalanceImpl 和 ProcessQueue 相关源码。定位到 rebalanceByTopic 的逻辑：实例新增或下线后，会重新计算队列分配，老的 ProcessQueue 被标记为 dropped，新实例接管队列后，如果 broker 上存的 offset 偏旧，就会从旧位点重新拉消息。

当时我们的消费端代码为了追求高性能，把消费者实例的线程数调得比较大，并且 consumeMessageBatchMaxSize 设置成 32。这样处理完一批消息后，实际上会有更长的 window，才上报一次 offset。在 rebalance 触发的瞬间，已经处理但未上报的消息就会重复。

解决的组合拳是：适度减小 consumeMessageBatchMaxSize，让 offset 上报更频繁；在扩容/重启时，先通过运维脚本把消费者实例逐个摘流量，再串行发布，避免同时多个实例下线触发大规模 rebalance。当然，最后还是给业务表加了唯一键兜底。

6.3 总结一下我的体会

源码翻得再多，最终都要落在一个事实上：RocketMQ 从设计上接受重复，业务层必须自带幂等。七个根源里，运维和架构层面的问题可以通过参数调整和发布流程优化来减少，但永远无法完全消除。唯一能让你睡安稳觉的，就是在业务关键链路上把幂等做扎实。

如果看完这篇，你至少能明白两件事：第一，重复消费不是某个人的 bug，而是分布式系统下的固有概率，生产投递会重复、broker 确认会重复、消费 offset 更是天然有窗口；第二，遇到重复消费别慌，先定段，再定源，最后用适配业务场景的幂等方案收口。这套思路，比单点排查某个队列要有用得多。