背景
公司已上线的项目中的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，后面继续观察一段时间。
博主：测试生财（一个不为996而996的测开码农）
座右铭：专注测试开发与自动化运维，努力读书思考写作，为内卷的人生奠定财务自由。
内容范畴：技术提升，职场杂谈，事业发展，阅读写作，投资理财，健康人生。
csdn：https://blog.csdn.net/ccgshigao
博客园：https://www.cnblogs.com/qa-freeroad/
51cto：https://blog.51cto.com/14900374
微信公众号：测试生财（定期分享独家内容和资源）
