本文正在参加「Java应用线上问题排查经验/工具分享」活动

先点赞再看，养成好习惯
背景
全国最大的短信平台，大家都用过我们的产品。数据量比较大，最多时候一天近7亿条短信。
我们项目从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的时候，就是打开锁（属性名翻译一下也大概是这个意思），然后关键代码其实还是单线程处理；