性能文章>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;原创

https://a.perfma.net/img/2521381
2年前
716036

本文正在参加「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后面打印

image.png

image.png

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

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

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

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

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

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

点赞收藏
分类:标签:
Chay
请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

日常Bug排查-集群逐步失去响应

日常Bug排查-集群逐步失去响应

浅析AbstractQueuedSynchronizer

浅析AbstractQueuedSynchronizer

6
3