RocketMQ broker busy的示例分析

首先，broker busy 相关的日志关键字如下：

• [REJECTREQUEST]system busy

• too many requests and system thread pool busy

• [PC_SYNCHRONIZED]broker busy

• [PCBUSY_CLEAN_QUEUE]broker busy

• [TIMEOUT_CLEAN_QUEUE]broker busy

本文先给出一张流程图，展示上述5种 broker busy 分别会在消息发送的哪个阶段抛出，以便大家能够清晰的了解其发生的原因。

 

同时在做 Broker 服务器巡检的时候，可以通过去通过如下命令去查看 broker 一次消息追加是否会超过 500 ms。

 

本文接下来想重点探讨一下 [TIMEOUT_CLEAN_QUEUE]broker busy 这种情况。

BrokerFastFailure#cleanExpiredRequest

while (true) {
    try {
        if (!this.brokerController.getSendThreadPoolQueue().isEmpty()) {
            final Runnable runnable = this.brokerController.getSendThreadPoolQueue().peek();
            if (null == runnable) {
                break;
            }
            final RequestTask rt = castRunnable(runnable);
            if (rt == null || rt.isStopRun()) {
                break;
            }

            final long behind = System.currentTimeMillis() - rt.getCreateTimestamp();
            if (behind >= this.brokerController.getBrokerConfig().getWaitTimeMillsInSendQueue()) {
                if (this.brokerController.getSendThreadPoolQueue().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, this.brokerController.getSendThreadPoolQueue().size()));
                }
            } else {
                break;
            }
        } else {
            break;
        }
    } catch (Throwable ignored) {
    }
}

可以看出来，抛出这种错误，在 broker 还没有发送“严重”的 pagecache 繁忙，即消息追加到内存中的最大时延没有超过 1s，通常追加是很快的，绝大部分都会低于1ms，但可能会由于出现一个超过200ms的追加时间，导致排队中的任务等待时间超过了200ms，则此时会触发broker 端的快速失败，让请求快速失败，便于客户端快速重试。但是这种请求并不是实时的，而是每隔10s 检查一遍。

值得注意的是，一旦出现 TIMEOUT_CLEAN_QUEUE，可能在一个点会有多个这样的错误信息，具体多少与当前积压在待发送队列中的个数有关。