深度挖掘RocketMQ底层那些导致消息丢失的汇总透析（TIMEOUT_CLEAN_QUEUE）

为什么单独介绍TIMEOUT_CLEAN_QUEUE

问题引发原因

针对之前的两篇文章中所出现的 [XXX - broker busy] 问题主要是由于Broker在追加消息时持有的锁时间超过了阈值（默认为1s），Broker为了自我保护，会实现快速失败->抛出错误，客户端会选择其他Broker服务器进行重试。

之前方案的解决手段

除非是银行或金融级的业务服务，否则个人建议将transientStorePoolEnable = true，可以有效缓解和避免之前的 【XXX - broker busy】 问题 。

方案运行原理

发送的消息数据，首先会存储在DirectBuffer(堆外内存)中，而且RocketMQ提供了内存锁定的功能，文件顺序读写的性能没有什么问题，因此实现了分流处理，做到在内存使用层面的读写分离，

• 写消息是直接写入DirectBuffer堆外内存
• 读消息直接从PageCache中读
• 定时将堆外内存的消息写入PageCache。

但随之带来的就是可能存在消息丢失，如果对消息非常严谨的话，建议扩容集群，或迁移topic到新的集群。

TIMEOUT_CLEAN_QUEUE]broker busy

了解了上面的错误信息之后，我们接下来需要看一下TIMEOUT_CLEAN_QUEUE]broker busy的问题是什么原因导致的以及如何进行避免！

MQBrokerException：CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue：
235ms，size of queue:875
复制代码

问题探索分析

当Broker端由于性能问题以及服务端积压的请求太多从而得不到及时处理，会极大的造成客户端消息发送的时间延长。

案例背景

假设RocketMQ写入一条消息需要100ms，此时由于TPS过高引发队列中积压了2000条数据，而消息发送端的默认超时时间为3s，如果按照这样的速度，这些请求在轮到Broker执行写入请求时，客户端已经将这个请求超时了，这样不仅会造成大量的无效处理，还会导致客户端发送超时。

TIMEOUT_CLEAN_QUEUE的由来

RocketMQ为了解决这种由于性能锁带来的频发问题，引入Broker端快速失败机制，即开启一个定时调度线程，每隔10毫秒去检查队列中的第一个排队节点，如果该节点的排队时间已经超过了200ms。就会取消该队列中所有已超过 200ms 的请求，立即向客户端返回失败。

结合客户端重试机制创造数据补偿体系

客户端能尽快进行重试，因为Broker都是集群部署，下次重试可以发送到其他 Broker 上，这样能最大程度保证消息发送在默认 3s 的时间内经过重试机制，能有效避免某一台 Broker 由于瞬时压力大而造成的消息发送不可用，从而实现消息发送的高可用。

源码流程分析

如果要分析问题，我们首先还是需要进行分析和探索以下源码。