背景

公司已上线的项目中的broker集群有部分请求响应较慢，所以进行了线上broker服务的扩容。扩容后整体broker集群的负载下来了不少。这样一周后，某天看rocketmq的客户端的日志中零星打印了报错：system busy。

问题分析

为什么broker集群扩容了，仍旧有报错呢？和开发对了下，我们broker集群搭建在公有云虚拟机上的，所以可能有以下情况：

1. 网络拥塞/抖动

公有云的网络环境是未知的，可能是实际线路上的网络调整，或者公有云上的网络服务上线问题导致。

2. 虚机资源不稳定

虚机是搭建在物理机上的，不排除虚机资源调度导致虚机在某一时刻的资源不足。

3. 客户端流量异常

在某一时刻，客户端请求broker的流量积压后，在某一时刻突然增大。

4. broker内部处理有bug。

其中第一种和第二种情况是不好定位的，基础环境问题我们没有办法排查；第三种情况，经过排查，没有发现有流量积压，当然不排除客户端有bug；第四种，由于我们不是做rocketmq的，如果真是rocketmq本身有bug，我们也解决不了，或者说线上broker单机压力才1000多tps，我觉得不应该达到broker的上限（线下测试基本是1wtps）

最后和开发对了下，看是否有一些能优化broker出现这种系统繁忙的配置，最后发现了一个配置项：maxWaitTimeMillsInQueue

if (behind >= maxWaitTimeMillsInQueue) {
　　if (blockingQueue.remove(runnable)) {
　　　　rt.setStopRun(true);
　　　　rt.returnResponse(RemotingSysResponseCode.SYSTEM_BUSY, String.format("[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: %sms, size of queue: %d", behind, blockingQueue.size()));
　　}
} else {
　　　　break;
}

这里可以看到如果大于了maxWaitTimeMillsInQueue这个时间，最终会返回一个system busy，告诉rocketmq的客户端进行流量控制。

所以修改这个参数，能够在一定程度上降低system busy出现的概率（当然前提是broker所在机器的资源比较富足的情况下，如果本身broker所在机器就资源不足，修改这个会雪上加霜）。

目前尝试将maxWaitTimeMillsInQueue设置为1500，即快速失败判断时间大于1.5s才返回system busy，后面继续观察一段时间。

传送门：2021最新测试资料与大厂招聘合集

博主：测试生财（一个不为996而996的测开码农）

座右铭：专注测试开发与自动化运维，努力读书思考写作，为内卷的人生奠定财务自由。

内容范畴：技术提升，职场杂谈，事业发展，阅读写作，投资理财，健康人生。

csdn：https://blog.csdn.net/ccgshigao

博客园：https://www.cnblogs.com/qa-freeroad/

51cto：https://blog.51cto.com/14900374

微信公众号：测试生财（定期分享独家内容和资源）