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后面打印

Rocketmq发送时异常system busy,start flow control for a while;broker busy start flow control for a while;

Rocketmq发送时异常system busy,start flow control for a while;broker busy start flow control for a while;

system busy,然后响应超时,消费组不存在,换另一台继续连,又是响应超时,然后再换一台,继续是。经过这些异常信息查询出来相关配置,下面就是相关解释。

外国友人说的很明白,你有两个选择;我选择了后者,我们的数据量略大,每天上亿的数据,需要mq来支撑。

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

Rocketmq发送时异常system busy,start flow control for a while;broker busy start flow control for a while;

  sendMessageThreadPoolNums这个属性是发送线程池大小(这个数值建议是服务器多少核乘以2倍), rocketmq4.1版本之后默认为 1,之前版本默认什么不知道但是肯定大于1。这个属性改成1的话,就不用管useReentrantLockWhenPutMessage这个属性了;

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

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

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

如有其它疑问请加群号:168733660 欢迎骚扰;