消息发出去没收到确认到底该不该重发、隔多久重发、重发几次才放弃——这套逻辑但凡做过分布式系统的人都绕不开。RocketMQ 的消息重试机制就是专门解决这个问题的它把失败之后怎么办这件事从业务代码里抽出来交给中间件统一处理让生产者、消费者各自有一套清晰的重试规则。这篇内容我打算把 RocketMQ 重试机制从设计动机到落地细节完整拆一遍包括生产端重试和消费端重试的区别、重试队列怎么组织、重试间隔为什么这么设计、死信队列怎么兜底以及我在实际项目里踩过的坑。适合正在用 RocketMQ 做异步解耦、削峰填谷的开发者也适合刚接触消息中间件、想搞明白消息可靠性到底靠什么保证的同学。读完你至少能判断什么场景该开重试、重试参数怎么调、消费失败后消息到底去哪了。1. 重试机制的整体设计与思路拆解1.1 为什么重试必须由中间件来做先想一个最朴素的问题如果 RocketMQ 不提供重试机制业务代码会变成什么样生产者发送失败你得自己写循环重发消费者处理失败你得自己把消息塞回某个地方再定时捞出来。每个业务团队都写一遍重复劳动不说重试次数、重试间隔、失败兜底各写各的线上出问题时根本没法统一排查。把重试收归中间件本质上是把可靠性这件事标准化。生产者只需要关心我发出去的消息有没有被 Broker 确认消费者只需要关心我这条消息处理成功还是失败中间的重发节奏、失败记录、最终兜底全部由 RocketMQ 内部消化。这个设计思路和数据库的事务回滚是一个道理——把通用的容错逻辑下沉到基础设施层业务层保持干净。从架构上看RocketMQ 的重试分成两条完全独立的链路生产端重试解决的是消息有没有成功到达 Broker消费端重试解决的是消息到达消费者之后有没有被成功处理。这两条链路的重试对象、触发条件、实现机制都不一样很多人混淆就是因为没把这两件事分开看。1.2 生产端与消费端的职责边界生产端重试的核心判断依据是发送结果。RocketMQ 的发送方式分三种同步发送、异步发送、单向发送。同步发送会拿到明确的 SendResult状态不是 SEND_OK 就可以重试异步发送通过回调拿到结果失败同样可以重试单向发送压根不关心结果所以单向发送没有重试——这一点经常被忽略有人用单向发送追求吞吐结果消息丢了都不知道。消费端重试的判断依据则是消费逻辑的返回值。这里有个关键设计RocketMQ 把消费失败的语义交给了消费者自己表达。你返回 CONSUME_SUCCESS 就是成功返回 RECONSUME_LATER 或者抛异常就是失败失败的消息会被投递到重试队列等待下一次投递。这个设计的好处是业务可以精确控制哪些失败值得重试——比如参数校验不通过这种重试一万次也不会成功的错误你就该返回成功把它消化掉而不是让它反复重试最后进死信。1.3 重试机制要解决的核心矛盾重试这件事看起来简单实际上要在三个矛盾之间找平衡。第一是可靠性与重复消费的矛盾重试必然带来重复投递的可能所以消费端必须做幂等这是重试机制成立的前提。第二是及时性与系统压力的矛盾失败后立刻重试可能把下游打垮间隔太久又影响业务时效RocketMQ 用递增的间隔策略来折中。第三是重试次数与消息不丢的矛盾重试不能无限进行必须有上限超过上限的消息不能直接扔掉得有死信队列兜底。这三个矛盾决定了 RocketMQ 重试机制的整体形态生产端有限次数快速重试、消费端分级延迟重试、超限进死信人工介入。理解了这层设计动机后面看具体参数和队列结构就不会觉得是死记硬背了。2. 生产端重试的核心细节与实操要点2.1 同步发送的重试逻辑与参数同步发送是生产端重试最典型的场景。RocketMQ 客户端内置了重试逻辑核心参数是retryTimesWhenSendFailed默认值在不同版本里有差异常见默认是 2也就是首次发送失败后最多再重试 2 次总共 3 次尝试。这个参数可以在创建 Producer 时通过setRetryTimesWhenSendFailed调整。这里有个容易被误解的点重试不是无脑重发同一条消息到同一个 Broker。RocketMQ 在重试时会尽量选择不同的 Broker避免因为单个 Broker 故障导致重试全部打在一个点上。这个选择逻辑藏在sendKernelImpl里它会根据延迟、故障等因素做 Broker 选择。所以生产端重试天然带有一定的故障转移能力这也是它比业务层自己写循环重发更靠谱的地方。同步发送重试的触发条件需要说清楚只有发送过程抛出异常、或者返回的状态不是 SEND_OK 时才会触发。像 FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、SLAVE_NOT_AVAILABLE 这些状态消息其实已经写进 Broker 了只是刷盘或主从同步没达到预期这类情况客户端默认也会重试但你要意识到这可能导致消息重复——所以生产端的重试同样要求消费端幂等。DefaultMQProducer producer new DefaultMQProducer(producer_group_demo); producer.setNamesrvAddr(127.0.0.1:9876); // 同步发送失败重试次数默认2次 producer.setRetryTimesWhenSendFailed(2); // 发送超时时间超时也会触发重试 producer.setSendMsgTimeout(3000); producer.start(); Message msg new Message(topic_demo, tag_a, hello rocketmq.getBytes()); SendResult result producer.send(msg); if (result.getSendStatus() ! SendStatus.SEND_OK) { // 走到这里说明重试耗尽仍未成功需要业务兜底 log.error(send failed after retry, status{}, result.getSendStatus()); }上面这段代码里setSendMsgTimeout值得单独说。超时时间设得太短网络稍微抖一下就触发重试白白增加重复消息设得太长失败感知慢影响整体吞吐。我一般按 P99 网络延迟的 2 到 3 倍来设内网环境 3000ms 是个比较稳的起点。2.2 异步发送与单向发送的差异异步发送的重试参数是retryTimesWhenSendAsyncFailed逻辑和同步类似失败后在回调里能拿到异常。异步发送适合对吞吐要求高、又需要知道发送结果的场景。要注意异步发送的重试是在回调线程里触发的如果重试次数多、并发高回调线程池可能成为瓶颈这个在压测时容易暴露。单向发送sendOneway则是另一回事它发出去就不管了没有 SendResult自然也没有重试。用单向发送的场景通常是日志采集这类丢了也能接受的数据如果你用它传业务关键消息那消息可靠性就无从谈起了。我见过有团队为了追求吞吐把订单状态变更用单向发送结果对账时发现状态缺失排查了半天才定位到是发送方式选错了。2.3 生产端重试的注意事项生产端重试有几个实操层面的坑值得提前说。第一重试次数不是越多越好。重试次数多意味着单次发送的耗时上限变高在 Broker 整体不可用时生产者线程会被长时间占用可能拖垮上游服务。第二重试和超时要配合看总耗时约等于重试次数1× 超时时间这个值要小于上游调用的超时预算。第三批量发送的重试粒度是整批一批里有一条失败整批重发重复范围更大所以批量发送对幂等的要求更高。提示生产端重试只能保证尽力送达不能保证一定送达。真正要保证不丢还需要配合 Broker 的同步刷盘、主从同步等持久化策略重试只是其中一环。3. 消费端重试的队列结构与投递机制3.1 重试队列的组织方式消费端重试是 RocketMQ 重试机制里最有意思的部分。消费者处理失败后消息不会原地等待而是被投递到一个特殊的队列——重试队列。这个队列的命名规则是%RETRY%加上消费者组名比如消费者组叫consumer_group_demo重试队列就是%RETRY%consumer_group_demo。这里有个关键细节重试队列是按消费者组维度创建的不是按 Topic。也就是说同一个 Topic 被多个消费者组订阅每个消费者组各有各的重试队列互不干扰。这个设计很合理——不同消费者组的处理能力和失败情况不同重试节奏本来就该独立。重试队列本身也是一个真实的 Topic只不过以%RETRY%开头由 Broker 自动创建和管理。消息进入重试队列后会按照预设的延迟级别等待到点后重新投递给消费者组。消费者组重新消费时消息的 Topic 会被还原成原始 Topic但消息属性里会带上重试次数消费者可以通过MessageExt.getReconsumeTimes()拿到当前是第几次重试。3.2 重试间隔的延迟级别设计RocketMQ 消费端重试用的是延迟消息的机制延迟级别对应一组预设的时间间隔。默认的延迟级别是 18 级从 1s 开始逐级递增常见的对应关系如下表延迟级别延迟时间延迟级别延迟时间11s106m25s117m310s128m430s139m51m1410m62m1520m73m1630m84m171h95m182h消费失败的消息第 n 次重试会使用第 n 级延迟。也就是说第一次失败等 1s 重试第二次失败等 5s第三次等 10s以此类推。这个递增设计背后的逻辑很直白失败往往是下游临时故障短间隔快速重试能抓住瞬时抖动如果连续失败说明问题可能比较严重拉长间隔既给下游恢复时间也避免无效重试把系统压垮。默认最大重试次数是 16 次对应到延迟级别就是用到第 16 级30 分钟。16 次重试全部失败后消息进入死信队列。这个 16 次的总时长加起来相当可观从秒级一直拉到半小时级给了下游充分的恢复窗口。3.3 并发消费与顺序消费的重试差异这里必须区分两种消费模式。并发消费MessageListenerConcurrently下失败消息进重试队列按上面的延迟级别重投这是主流用法。顺序消费MessageListenerOrderly下情况不一样为了保证顺序RocketMQ 不会把失败消息扔进重试队列打乱顺序而是在当前队列上本地重试通过setSuspendCurrentQueueTimeMillis控制挂起时间默认会一直重试直到成功或者达到最大次数。顺序消费的这个设计是必然的——顺序消息一旦进重试队列重新投递时就可能排到别的消息后面顺序就乱了。所以顺序消费的重试代价更高它会阻塞当前队列的后续消息。这也是为什么顺序消费场景要格外注意消费逻辑的健壮性一条消息卡住整个队列都跟着停。3.4 消费端重试的实操配置消费端重试次数可以通过setMaxReconsumeTimes调整。并发消费默认 16 次顺序消费默认是 Integer.MAX_VALUE实际受限于本地重试策略。调小重试次数适合那些失败基本就是业务错误、重试无意义的场景能更快把消息推进死信队列减少无效重试。DefaultMQPushConsumer consumer new DefaultMQPushConsumer(consumer_group_demo); consumer.setNamesrvAddr(127.0.0.1:9876); consumer.subscribe(topic_demo, *); // 最大重试次数超过后进入死信队列 consumer.setMaxReconsumeTimes(5); consumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) - { for (MessageExt msg : msgs) { try { // 业务处理 handleMessage(msg); } catch (Exception e) { int reconsumeTimes msg.getReconsumeTimes(); log.warn(consume failed, reconsumeTimes{}, reconsumeTimes, e); // 返回稍后重试 return ConsumeConcurrentlyStatus.RECONSUME_LATER; } } return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }); consumer.start();这段代码里有个实践细节拿到reconsumeTimes之后可以做分级处理。比如前几次失败按正常重试走接近最大次数时打告警日志方便运维提前介入而不是等消息进了死信队列才发现。4. 死信队列与失败兜底策略4.1 死信队列的触发条件与结构重试次数耗尽的消息不会凭空消失而是进入死信队列命名规则是%DLQ%加消费者组名。死信队列里的消息意味着系统已经尽力了需要人工或专门的补偿程序介入。这个兜底设计是消息可靠性闭环的最后一环没有它重试机制就是不完整的。死信队列有几个特性要清楚。第一死信队列默认只读不写普通消费者不能直接订阅消费需要通过管理工具或者专门的运维程序去读取处理。第二死信消息保留了原始消息的所有属性包括原始 Topic、重试次数、失败时间等方便排查。第三死信队列不会自动清理需要配置清理策略或者人工处理否则会一直堆积。4.2 死信处理的常见方案死信处理没有标准答案取决于业务对消息的容忍度。常见方案有三种。第一种是人工介入通过管理控制台查看死信消息分析失败原因后手动重投或丢弃适合死信量小、需要人工判断的场景。第二种是自动补偿程序写一个定时任务扫描死信队列按规则重新投递到原始 Topic 或者转入补偿表适合失败原因可自动判定的场景。第三种是落库归档把死信消息持久化到数据库后续通过业务系统处理适合需要长期追溯的场景。我个人的经验是死信队列一定要配监控告警。死信堆积往往意味着某个下游出了系统性问题早发现早处理比事后翻日志强得多。告警阈值可以按业务量设比如死信数量超过 100 条或者增长率异常就触发。4.3 重试与死信的监控指标要把重试机制用稳监控得跟上。核心指标包括重试队列的消息堆积量、重试次数的分布、死信队列的增长速率、消费失败率。重试次数分布特别有用——如果大量消息集中在第 1 到 2 次重试就成功了说明是瞬时抖动系统整体健康如果大量消息重试到接近上限说明下游有持续性问题得赶紧查。注意重试队列和死信队列都是按消费者组创建的消费者组下线后这些队列不会自动删除长期积累会占用存储。定期清理不再使用的消费者组对应的重试和死信队列是个容易被忽略的运维动作。5. 常见问题排查与避坑经验实录5.1 消息重复消费的排查思路重试机制最直接的副作用就是重复消费这是绕不开的。排查重复消费先要区分是生产端重试导致的重复还是消费端重试导致的重复。生产端重复的特征是同一条消息在 Broker 里有多份可以通过消息的唯一 Key 去查消费端重复的特征是消息只有一份但被消费了多次看消费日志里同一消息 ID 出现多次就能确认。解决重复消费的根本手段是消费幂等。幂等的实现方式很多用业务唯一键做数据库唯一索引、用 Redis 记录已处理的消息 ID、用状态机保证状态只能单向流转。选哪种取决于业务特点但核心思路一致——同一条消息处理多次和处理一次的结果必须相同。这里要提醒一句幂等判断本身也可能失败比如 Redis 挂了所以幂等方案也要考虑降级。5.2 重试不生效的典型原因有人反馈我明明返回了 RECONSUME_LATER怎么没看到重试。这种情况先查几个点。第一确认返回的是ConsumeConcurrentlyStatus.RECONSUME_LATER而不是抛了异常又被外层吞掉。第二确认消费者组没有配置成广播模式——广播模式下的消费失败不会进重试队列这是很多人踩的坑广播模式每个实例都消费全量消息重试语义没法统一定义所以 RocketMQ 直接不支持。第三确认消息没有因为超过最大重试次数直接进了死信队列。还有一个隐蔽的坑消费监听器里如果开了子线程异步处理主线程直接返回了 CONSUME_SUCCESS那子线程里的失败根本不会被 RocketMQ 感知自然不会重试。这种写法在追求消费吞吐时很常见但代价就是失去了重试能力得自己在子线程里做补偿。5.3 重试导致消息积压的应对重试队列堆积是另一个高频问题。下游故障时大量消息消费失败进入重试队列重试队列本身也是要消费的如果下游一直不恢复重试消息越堆越多最终可能拖垮整个消费者组。应对思路分短期和长期。短期可以临时调大消费者线程数、扩容消费者实例先把积压消化掉长期则要审视重试次数和间隔配置是否合理下游是否有足够的熔断降级能力。这里有个反直觉的经验下游故障时适当调小最大重试次数反而更稳。因为重试次数多意味着消息在系统里反复流转的时间长占用资源多不如快速失败进死信队列等下游恢复后统一补偿。这个取舍要看业务对时效的要求不能一概而论。5.4 常见问题速查表问题现象可能原因排查方向消息重复消费生产端重试或消费端重试查消息唯一 Key 是否多份查消费日志返回 RECONSUME_LATER 不重试广播模式、子线程异步处理、已达最大次数查消费模式、查监听器实现、查重试次数重试队列大量堆积下游持续故障、重试间隔过短查下游健康度、评估重试参数死信队列持续增长业务逻辑错误、重试次数配置不当抽样死信消息分析失败原因顺序消费卡住某条消息本地重试阻塞队列查顺序消费监听器异常处理逻辑5.5 几个实操层面的小技巧分享几个我在项目里总结的小技巧。第一消费失败时把异常信息和重试次数一起打进日志排查时能快速定位是偶发还是系统性问题。第二给重试次数设分级告警比如重试到第 5 次打 warn到第 10 次打 error 并通知值班别等进死信才反应。第三死信队列配一个自动巡检脚本每天统计死信数量和类型形成趋势图异常增长一眼就能看出来。第四压测时专门构造消费失败场景验证重试链路和死信兜底是否按预期工作别等线上出事才发现配置有问题。重试机制这套东西配置起来就几个参数但要用稳靠的是对失败场景的预判和监控的完善。参数是死的业务对失败的容忍度是活的把两者对上重试才真正起到兜底作用而不是制造新的问题。
