本文主要是介绍Rocketmq发送时异常system busy,start flow control for a while；broker busy start flow control for a while，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我们项目从RocketMQ3.2.6过渡到4.5.0版本，从alibaba的过渡到apache下，出现这个问题。
测试人员在大量压测的情况下出现这个问题。QPS超过1000.
1、system busy , start flow control for a while
该异常会造成 消息丢失。
2、broker busy , start flow control for a while
该异常不会造成消息丢失。
我们系统的日志是格式化过得，exception在m->q后面打印
system busy,然后响应超时，消费组不存在，换另一台继续连，又是响应超时，然后再换一台，继续是。经过这些异常信息查询出来相关配置，下面就是相关解释。
外国友人说的很明白，你有两个选择；我选择了后者，我们的数据量略大，每天上亿的数据，需要mq来支撑。
sendMessageThreadPoolNums这个属性是发送线程池大小（这个数值建议是服务器多少核乘以2倍）， rocketmq4.1版本之后默认为 1，之前版本默认什么不知道但是肯定大于1。这个属性改成1的话，就不用管useReentrantLockWhenPutMessage这个属性了；
如果改成大于1，就需要将useReentrantLockWhenPutMessage这个属性设置为 true；
目前测试 未发现这两个方案有什么区别，sendMessageThreadPoolNums=1 时也支持多线程发送，发送速度感觉和 sendMessageThreadPoolNums大于1没有区别，都能跑满100M的网卡。
感觉如果useReentrantLockWhenPutMessage=true的时候，就是打开锁（属性名翻译一下也大概是这个意思），然后关键代码其实还是单线程处理；
这篇关于Rocketmq发送时异常system busy,start flow control for a while；broker busy start flow control for a while的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
