1、问题现象
首先接到项目反馈使用 RocketMQ 会出现如下错误:

错误信息关键点:MQBrokerException:CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。
由于项目组并没有对消息发送失败做任何补偿,导致丢失消息发送失败,故需要对这个问题进行深层次的探讨,并加以解决。
2、问题分析
首先我们根据关键字:TIMEOUT_CLEAN_QUEUE 去 RocketMQ 中查询,去探究在什么时候会抛出如上错误。根据全文搜索如下图所示:

该方法是在 BrokerFastFailure 中定义的,通过名称即可以看成其设计目的:Broker端快速失败机制。
Broker 端快速失败其原理图如下:

消息发送者向 Broker 发送消息写入请求,Broker 端在接收到请求后会首先放入一个队列中(SendThreadPoolQueue),默认容量为 10000。
Broker 会专门使用一个线程池(SendMessageExecutor)去从队列中获取任务
RocketMQ一行代码致大量消息丢失问题解析

本文分析了RocketMQ在特定情况下出现TIMEOUT_CLEAN_QUEUE错误,导致消息丢失的问题。问题源于Broker的快速失败机制,且在异常处理中缺少对SYSTEM_BUSY的重试。解决方案包括增加waitTimeMillsInSendQueue值和修复RocketMQ的BUG,同时建议业务方自建消息重试机制以确保高可用性。
最低0.47元/天 解锁文章
1093

被折叠的 条评论
为什么被折叠?



