RocketMQ-消息发送源码分析(三)消息重试及Broker故障延迟机制

最新推荐文章于 2025-04-02 20:45:46 发布
原创 最新推荐文章于 2025-04-02 20:45:46 发布 · 2.3k 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#RocketMQ #消息重试 #故障转移 #队列选择

本文深入分析RocketMQ消息发送时的队列选择策略，包括默认机制和Broker故障转移机制。在消息发送失败时，RocketMQ会进行重试，同步模式下最多重试3次。默认机制通过线程变量选择队列，而故障转移机制通过预测Broker不可用时长来避免向故障Broker发送消息，提高发送高可用性。

文章目录

问题点

上篇文章已经介绍了消息发送时，topic的路由信息是如何获取的，最终路由结果是一个TopicPublishInfo对象，其中messageQueueList就是本次消息发送的topic对应的消息队列，再看下TopicPublishInfo属性图加深印象
在这里插入图片描述

问题又来了，拿到了消息队列后，就进入到了具体消息队列选择、发送的流程，所以有如下问题

1、消息队列是如何选择的，即producer向哪个消息队列里发送消息？
2、消息发送失败了怎么办(网络原因，broker挂掉)？发送端如何实现的高可用？

具体消息发送的实现在org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl#sendKernelImpl中，下篇文章再做介绍，本文主要关注于消息发送时的队列选择、重试机制、及Broker故障延迟机制

消息重试

看下获取到了路由信息后的发送代码
在这里插入图片描述
可以看到timesTotal(发送次数)在同步模式下被设为1+this.defaultMQProducer.getRetryTimesWhenSendFailed()=3次，异步或者oneway模式为1次

即消息发送失败后，同步模式会重试2次，for循环内部的逻辑代码如下

最低0.47元/天 解锁文章

新学期VIP享超值加赠
RocketMQ源码分析：Producer中延迟故障机制
2301_76607156的博客
03-25 364
RocketMQ中的延迟故障机制是为了帮助Producer能够通过消息发送延迟或者消息发送结果主动感知Broker忙碌或者故障，消息发送延迟或者消息发送失败时可以将Broker排除在选择列表之外。这个机制默认是不开启的，如果需要开启这个机制需要在创建Producer时主动开启。
第二章-RocketMQ源码解析-生产者-普通消息发送
zhang527294844的博客
03-25 1142
RocketMQ源码解析-生产者-普通消息发送
RocketMQ学习笔记：Broker故障延迟机制
weixin_45003125的博客
03-25 2158
RocketMQ学习笔记：Broker故障延迟机制Broker故障延迟机制是什么 《RocketMQ技术内幕》学习笔记 Broker故障延迟机制是什么 当producer发送消息失败并且开启了重试机制（retryTimesWhenSendFailed=true或retryTimesWhenSendAsyncFailed=true），接下来将会重新选择消息队列，那么是如何进行重新选择消息队列的呢...
Rocketmq 故障延迟 源码解析
kznsbs的博客
12-29 758
故障延迟 在 rocketmq 中，有两种延迟机制 1. 开启故障延迟 2. 关闭故障延迟（默认） 关闭故障延迟 通过 sendLatencyFaultEnable = false 表示关闭故障延迟 所谓的关闭故障延迟就是，在生产者发送消息的时候，可能因为网络原因或者是其他外接因素，导致消息发送失败，这个时候就会进行消息发送的重试（单向消息除外）那么在 broker 端机会记录一下这个失败的broker，所以下次轮询到这个broker 的时候就会跳过这个broker，这样就减少了消息发送失败的概率 这里关于
【RocketMQ|源码分析】Producer中延迟故障机制
MarcoLin
03-27 411
RocketMQ中的延迟故障机制是为了帮助Producer能够通过消息发送延迟或者消息发送结果主动感知Broker忙碌或者故障，消息发送延迟或者消息发送失败时可以将Broker排除在选择列表之外。这个机制默认是不开启的，如果需要开启这个机制需要在创建Producer时主动开启。
RocketMQ队列路由的故障延时机制深度解析
ly853602的博客
03-20 713
RocketMQ队列路由的故障延时机制深度解析
04 RocketMQ - Producer 源码分析
刘元雄
09-08 490
04 RocketMQ - Producer 源码分析
消息中间件-rocketmq-server.zip
01-31
通过对"rocketmq-server.zip"中的源码分析，开发者可以深入了解RocketMQ的内部工作机制，包括如何实现高并发、高可用以及消息的存储和传输策略。这对于定制化开发、优化性能或者排查问题具有极大的价值。
RocketMQ-3.2.6
03-12
- **消息回溯**: 可配置消息重试和回溯，确保消息不丢失。 - **消息过滤**: 提供客户端和服务器端的消息过滤机制，如SQL92过滤表达式。 - **消息轨迹追踪**: 提供消息轨迹查询功能，便于问题排查。 3. **...
RocketMQ之消费重试以及原理
daobuxinzi的博客
07-22 1882
对于顺序消息,当消费者消费消息失败后,消费者会在本地自动不断进行消息重试,每次间隔时间为 1 秒,重试最大值是 Integer.MAX_VALUE。对于无序消息(普通、定时、延时、事务消息)当消费者消费消息失败时可以通过设置返回状态达到重试的目的。广播模式下消息队列RocketMQ保证每条消息至少被每台客户端消费一次，但是并不会对消费失败的消息进行失败重投，因此业务方需要关注消费失败的情况。当消费者消费消息失败后,消费者会在本地自动不断进行消息重试,每次间隔时间为 1 秒,重试最大值是 Integer.MA
rocketmq 连接超时异常
新手新手新的博客
08-23 4087
记录一次小bug 在idea中连接RocketMQ，consumer端能用，但producer端一直报 sendDefaultImpl call timeout 超时异常 启动过程： nohup sh ./mqnamesrv nohup sh ./mqbroker -n localhost:9876 & 代码： // 消息的发送者 DefaultMQProducer mqProducer = new DefaultMQProducer("producer_Group"); mqProducer.s
rocketMQ：高可用实战--＞故障转译
weixin_43290370的博客
04-02 975
高可用的故障转移系统需要建立"检测-决策-执行-验证"的完整闭环。多维度动态阈值检测带人工干预回路的自动决策分级数据一致性保障硬件级快速故障发现这些经验对于构建金融级可靠的消息中间件具有重要参考价值。
11 RocketMQ主从原理、读写分离与故障转移
喜欢历史的码农
06-20 3689
前面已经了解过的内容如下： 集群中的每个Master Broker只存储一部分消息，通过主从保证高可用； 所有Brokerdou
Docker部署RocketMQ实现高可用与故障自动切换
Programming Talk
04-23 819
通过Docker Compose部署RocketMQ集群，不仅简化了部署流程，也便于管理和扩展。实现故障自动切换的关键在于合理配置Broker角色、数据同步机制以及利用客户端的重试逻辑。结合监控和告警系统，可以进一步提升系统的稳定性和响应速度，确保在任何情况下都能提供不间断的消息服务。随着Docker生态的不断成熟，RocketMQ在容器化环境下的应用将会更加广泛和深入。
rocketmq错误迁移导致问题排查
最简单的东西，往往包含了最复杂的实现。
11-30 1300
说明 最近由于测试环境机器老化，导致测试环境rocketmq集群有台机器关机了（那台机器有一个namesrv、一个master、一个另外的slave），后来起来了，运维告诉我们那台集群可能随时要坏，建议把里面的东西迁移，后来商量给了一台新的测试环境，第一次迁移rocketmq，想的简单了，导致了这次rocketmq错误迁移导致问题排查。记录下来，以后真实迁移不会出现这类问题了，也给大家一个参考吧。...
RocketMQ之MQFaultStrategy
诗人不写诗
03-12 758
在DefaultMQProducerImpl中聚合了一个对象 private MQFaultStrategy mqFaultStrategy = new MQFaultStrategy(); 这个类型主要是用来规划消息发送时的延迟策略。下面我们来研读下MQFaultStrategy这个类型： public class MQFaultStrategy { private final...
rocketMQ是如何利用MQFaultStrategy规避延迟故障的?
和我一起学习吧
07-20 652
RocketMq使用MQFaultStrategy规避超时失败，在RocketMq集群中，queue分布在各个不同的broker服务器中时，当尝试向其中一个queue发送消息时，如果出现耗时过长或者发送失败的情况，RocketMQ则会尝试重试发送。不妨细想一下，同样的消息第一次发送失败，极有可能是网络波动或者相关broker停止导致，如果短时间再次重试极有可能还是失败。.........
RocketMQ源码解析之消息生产者（容错）
猿上生活
10-29 838
我们在介绍生产者消息发送的时候
rocketmq源码分析 - producer发送消息的故障延迟机制
yuxiuzhiai的博客
12-28 883
概念 我们知道，生产者发送消息，需要发送到指定的MessageQueue上，如果发送失败了，则很可能说明这个MessageQueue所在的broker出现了某种问题，则在发送下一条消息或者重试的时候，需要尽可能的避免上次失败的broker。在rocketmq中，MQFaultStrategy负责做这件事情。 组件 LatencyFaultTolerance 用于判断一个broker是否有啥毛病。有...
探讨RocketMQ中TIMEOUT_CLEAN_QUEUE错误原因，分析Broker端快速失败机制及消息发送流程，提出修改SYSTEM_BUSY重试机制与实现业务方消息重试的解决方案。
最新发布
07-12
<think>嗯，用户这次的问题非常聚焦，是关于RocketMQ的TIMEOUT_CLEAN_QUEUE错误机制的深度优化需求。从提问的专业度来看，用户应该是有实际生产环境经验的开发者，遇到了消息积压导致的业务中断问题。 用户引用的资料很全面，从故障现象到源码分析都有覆盖。核心诉求其实分为三层：首先是理解Broker快速失败机制的原理（WHY），其次要掌握消息发送链路的全貌（HOW），最后需要可落地的优化方案（WHAT）。这种递进式提问说明用户已经做过基础排查，现在需要系统级解决方案。 注意到用户特别强调"业务方消息重试"这个点，暗示现有机制可能给业务带来了不可接受的消息丢失风险。结合引用[4]提到的"SYSTEM_BUSY不重试"现象，用户团队遇到的应该是客户端未正确处理Broker返回错误的情况。 技术层面要重点解析三个关键点：1）Broker端队列监控线程的工作原理，特别是那个200ms的等待时间阈值；2）客户端收到busy响应后的处理逻辑缺陷；3）业务层补偿机制如何与MQ原生重试协同。引用[3]提供的源码片段特别有价值，说明快速失败是发生在队列头元素超时场景。 解决方案需要分层设计：短期先用客户端重试策略止血，中期调整Broker线程参数平衡吞吐与延迟，长期必须建立业务幂等机制。考虑到用户生产环境现状，应该优先推荐风险最低的客户端配置优化方案。 值得提醒的是线程池参数调整存在隐性风险。比如增大sendMessageThreadPoolNums时，如果OS线程数不足反而会引起更严重的上下文切换开销。这些实操细节都要在方案中明确标注。</think>### RocketMQ TIMEOUT_CLEAN_QUEUE 错误深度解析与优化方案 --- #### **一、TIMEOUT_CLEAN_QUEUE 错误根本原因** 该错误本质是 **Broker 端的流量控制机制**，当消息处理队列出现拥塞时触发： 1. **队列头元素超时检测** Broker 会监控每个处理队列的首个任务等待时间。若超过阈值（默认 200ms），则触发清理并返回错误码： ```java // RocketMQ 源码逻辑 (简化) if (System.currentTimeMillis() - queueHead.waitTime > timeoutMills) { discardRequest(request); // 丢弃请求 return new Response(Code.SYSTEM_BUSY, "[TIMEOUT_CLEAN_QUEUE]broker busy"); } ``` [^3] 2. **触发场景** - 瞬时流量峰值超过 Broker 处理能力 - 磁盘 IO 延迟（如 Page Cache 刷盘阻塞） - 线程池资源不足（如 `sendMessageThreadPool` 满负荷）[^5] 3. **客户端表现** 生产者收到 `SYSTEM_BUSY` 错误码（对应 `TIMEOUT_CLEAN_QUEUE` 描述），此时**默认不重试**，直接抛出异常[^4]。 --- #### **二、Broker 快速失败机制与消息发送流程** ##### **消息发送核心链路** ```mermaid graph TD A[Producer] -->|SendMsg| B(Broker 接收线程) B --> C[Put Request to Queue] C --> D[Async Processing Thread] D -->|Write| E[CommitLog] E --> F[Dispatch to ConsumeQueue] ``` ##### **快速失败机制要点** 1. **设计目标**： 防止单个 Broker 过载导致集群雪崩，通过丢弃请求保护系统。 2. **监控维度**： - 队列头任务等待时间（`TIMEOUT_CLEAN_QUEUE`） - 系统负载（如 `OS page cache busy`） - 线程池拒绝次数 3. **副作用**： 客户端未实现重试时直接造成**消息丢失**[^2]。 --- #### **三、优化方案：多层级协同处理** ##### **1. 客户端重试机制强化** ```java // 生产者重试策略示例（Java） DefaultMQProducer producer = new DefaultMQProducer("GROUP"); producer.setRetryTimesWhenSendFailed(3); // 同步发送重试次数 producer.setRetryTimesWhenSendAsyncFailed(2); // 异步发送重试次数 producer.setRetryAnotherBrokerWhenNotStoreOK(true); // 自动切换Broker ``` **关键配置**： - `retryAnotherBrokerWhenNotStoreOK=true`：遇 `SYSTEM_BUSY` 时自动重试其他 Broker - 自定义重试策略：指数退避算法避免加重拥塞 ##### **2. Broker 端参数调优** | 参数 | 默认值 | 优化建议 | 作用 | |------------------------------|----------|------------------|--------------------------| | `waitTimeMillsInSendQueue` | 200ms | 300~500ms | 延长队列等待阈值 | | `sendMessageThreadPoolNums` | CPU核数+1 | 2*CPU核数 | 增加处理线程 | | `useReentrantLockWhenPutMessage` | false | true (高并发场景) | 减少线程竞争 | **配置示例**（`broker.conf`）： ```properties waitTimeMillsInSendQueue=400 sendMessageThreadPoolNums=32 useReentrantLockWhenPutMessage=true ``` ##### **3. 业务层容错设计** - **异步解耦**： 使用本地事务表 + 定时任务补偿，确保最终一致性： ```sql CREATE TABLE mq_compensate ( id BIGINT PRIMARY KEY, msg_body TEXT, status TINYINT DEFAULT 0 -- 0:待处理 1:已发送 ); ``` - **幂等消费**： 通过 `MessageId` + 业务唯一键实现重复消息过滤。 ##### **4. 集群级优化** - **读写分离**： 将 `SYSTEM_BUSY` 高频的 Broker 设为只读，由其他节点接管写入 - **自动扩容**： 监控 `RocketMQ_PendingTasks` 指标，达到阈值自动扩容 Broker 节点 --- #### **四、验证方案** 1. **压测模拟**： ```shell # 使用官方压测工具 ./tools.sh org.apache.rocketmq.example.benchmark.Producer \ -t TEST_TOPIC -w 5000 # 每秒5000消息写入 ``` 2. **监控看板**： - Broker：`PendingTaskCount`，`QueueWaitTime` - OS：`iowait`，`disk_util` - JVM：`GC Time`，`ThreadPoolRejectedCount` --- #### **五、典型误配置案例** > 某电商平台曾因误设 `waitTimeMillsInQueue=50ms`，导致大促时 60% 消息被丢弃。调整至 400ms 并配合客户端重试后，消息丢失率降至 0.001%[^1]。 --- ###
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值