RocketMQ broker busy的示例分析

首先，broker busy 相關(guān)的日志關(guān)鍵字如下：

• [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 分別會在消息發(fā)送的哪個階段拋出，以便大家能夠清晰的了解其發(fā)生的原因。

 

同時在做 Broker 服務(wù)器巡檢的時候，可以通過去通過如下命令去查看 broker 一次消息追加是否會超過 500 ms。

 

本文接下來想重點(diǎn)探討一下 [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 還沒有發(fā)送“嚴(yán)重”的 pagecache 繁忙，即消息追加到內(nèi)存中的最大時延沒有超過 1s，通常追加是很快的，絕大部分都會低于1ms，但可能會由于出現(xiàn)一個超過200ms的追加時間，導(dǎo)致排隊中的任務(wù)等待時間超過了200ms，則此時會觸發(fā)broker 端的快速失敗，讓請求快速失敗，便于客戶端快速重試。但是這種請求并不是實(shí)時的，而是每隔10s 檢查一遍。

值得注意的是，一旦出現(xiàn) TIMEOUT_CLEAN_QUEUE，可能在一個點(diǎn)會有多個這樣的錯誤信息，具體多少與當(dāng)前積壓在待發(fā)送隊列中的個數(shù)有關(guān)。