4-rocketmq 发送时异常：system busy 和 broker busy 解决方案

原文：https://www.cnblogs.com/enenen/p/10138511.html

　　这个文章从源码上分析了原因，并给出了解决方案。

　　文章解决方案一：在broker.config中将transientStorePoolEnable=true。

　　文章解决方案二：扩容broker服务器。

　　具体解决方案说明，可自行阅读文章。

------------------------以下为原内容--------------------------------------

　　之前写的解决方案,都是基于测试环境测试的.到生产环境之后,正常使用没有问题,生产环境压测时,又出现了system busy异常(简直崩溃).最后在rocketmq群里大佬指导下,终于解决(希望是彻底解决).

下面直接给出结果:

目前通过生产环境各种参数修改测试得出:

broker busy异常: 可通过增大 waitTimeMillsInSendQueue 解决

system busy异常:可通过增大 osPageCacheBusyTimeOutMills 解决

#发送队列等待时间

waitTimeMillsInSendQueue=3000

#系统页面缓存繁忙超时时间(翻译),默认值 1000

osPageCacheBusyTimeOutMills=5000

　　个人猜测,出现异常的原因是因为我们同一台服务器部署的多个应用造成的.我们一台服务器上部署了三个ES、八个redis、一个rocketmq ，压力测试时这些都在使用，虽然cpu、内存都还有很大剩余，但是磁盘io和内存频率毕竟只有那么多可能已经占满，或者还有其他都会有影响。

　　之前测试环境测试其他东西时，发现mq和redis同时大量使用时，redis速度会降低三到四倍，由此可见应用分服务器部署的重要性。以前知道会有影响，没想到影响这么大。

　　最终结解决方案:应该给rocketmq单独部署性能较高的服务器.

下面给下我们完整的配置:

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ 上面是最新更新 2019-06-13 ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

记一次 rocketmq 使用时的异常。

　　这里就不说什么rocketmq 源码啥的了，因为没看过。网上一搜这两个异常大部分都是什么源码解读，也没说出现后的解决办法（蓝瘦香菇）。

大量测试发现：

1、system busy , start flow control for a while

　　该异常会造成消息丢失。

2、broker busy , start flow control for a while

　　该异常不会造成消息丢失。（这是最坑的，都异常了消息竟然是正常发送了的。）

解决过程：

1、最开始时候，测试发现在性能好的服务器上只会出现system busy，也就是说出现异常就会消息丢失。

　　所以：业务代码进行处理，出现异常就会重发到当前topic的 bak队列，当时想的是既然这个topic busy了，就换到另外的topic去发，总不能都 busy吧。

也算是临时解决了。

2、运行一年后，可能是服务器上运行的东西多了，或者其他原因。发现有消息重复的现象。不用想肯定是报broker busy异常，重发到topic的 bak队列了。又因为broker busy可能不会造成消息丢失，所以消息重复就出现了。

3、无奈，找新的解决方法。本来想的是判断异常，如果是broker busy就不重发了。

报着试一试的态度，又去百度了一下，还是搜出来一堆源码解读。搭上梯子，google一下，还真找到了。

https://stackoverflow.com/questions/47749906/rocketmq-throw-exception-timeout-clean-queuebroker-busy-start-flow-control-f

https://www.cnblogs.com/cs99lzzs/p/9181555.html

想到不知道在哪看的的一句话，在stackoverflow上能找到和你一样的问题，那问题已经解决了百分之90了。这他喵的真实至理名言啊。

==============吐槽完=================

又经过大量测试验证：

解决方案：

修改rocketmq配置文件：

方案一：sendMessageThreadPoolNums 改成 1 ，没有的话新增一行。

　　sendMessageThreadPoolNums=1

方案二（推荐）：useReentrantLockWhenPutMessage改成true，没有的话新增一行。

　　sendMessageThreadPoolNums=32

　　useReentrantLockWhenPutMessage=true

说明：

　　sendMessageThreadPoolNums这个属性是发送线程池大小， rocketmq4.1版本之后默认为 1，之前版本默认什么不知道但是肯定大于1。这个属性改成1的话，就不用管useReentrantLockWhenPutMessage这个属性了；

　　如果改成大于1，就需要将useReentrantLockWhenPutMessage这个属性设置为 true；

　　目前测试未发现这两个方案有什么区别，sendMessageThreadPoolNums=1 时也支持多线程发送，发送速度感觉和 sendMessageThreadPoolNums大于1没有区别，都能跑满100M的网卡。

　　感觉如果useReentrantLockWhenPutMessage=true的时候，就是打开锁（属性名翻译一下也大概是这个意思），然后关键代码其实还是单线程处理；

　　有闲功夫的话去翻翻源码看看去。

　　最后我是选择的方案二，毕竟看着好看点。