一行程式碼造成大量訊息傳送失敗？RocketMQ神解決之終極踩坑經驗

codeGoogle發表於2021-08-06

1、問題現象

首先接到專案反饋使用 RocketMQ 會出現如下錯誤：

錯誤資訊關鍵點：MQBrokerException：CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue：205ms，size of queue:880。

由於專案組並沒有對訊息傳送失敗做任何補償，導致丟失訊息丟失，故需要對這個問題進行深層次的探討，並加以解決。

2、問題分析

首先我們根據關鍵字：TIMEOUT_CLEAN_QUEUE 去 RocketMQ 中查詢，去探究在什麼時候會丟擲如上錯誤。根據全文搜尋如下圖所示：

該方法是在 BrokerFastFailure 中定義的，通過名稱即可以看成其設計目的：Broker端快速失敗機制。

Broker 端快速失敗其原理圖如下：

訊息傳送者向 Broker 傳送訊息寫入請求，Broker 端在接收到請求後會首先放入一個佇列中(SendThreadPoolQueue)，預設容量為 10000。
Broker 會專門使用一個執行緒池(SendMessageExecutor)去從佇列中獲取任務並執行訊息寫入請求，為了保證訊息的順序處理，該執行緒池預設執行緒個數為1。

如果 Broker 端受到記憶體抖動等因素造成單條寫入資料發生抖動，單個 Broker 端積壓的請求太多還得不到及時處理，會極大的造成客戶端訊息傳送的延長時間，設想一下，如果由於 Broker 壓力增大，寫入一條訊息需要500ms甚至超過1s，並且佇列中積壓了5000條訊息，訊息傳送端的預設超時時間為3s，如果按照這樣的速度，這些請求在輪到 Broker 執行寫入請求時，客戶端已經將這個請求超時了，這樣不僅會造成大量的無效處理，還會導致客戶端傳送超時。

故 RocketMQ 為了解決該問題，引入 Broker 端快速失敗機制，即開啟一個定時排程執行緒，每隔10毫秒去檢查佇列中的第一個排隊節點，如果該節點的排隊時間已經超過了 200 ms，就會取消該佇列中所有已超過200ms的請求，立即向客戶端返回失敗，這樣客戶端能儘快進行重試，因為 Broker 都是叢集部署，下次重試可以傳送到其他 Broker 上，這樣能最大程度保證訊息傳送在預設3s的時間內經過重試機制，能有效避免某一臺 Broker 由於瞬時壓力大而造成的訊息傳送不可用，從而實現訊息傳送的高可用。

從 Broker 端快速失敗機制引入的初衷來看，快速失敗後會發起重試，除非同一深刻叢集內所有的 Broker 都繁忙，不然訊息會傳送成功，使用者是不會感知這個錯誤的，那為什麼使用者感知了呢？難道 TIMEOUT_CLEAN_QUEUE 錯誤，Broker 不重試？

為了解開這個謎團，接下來會採用原始碼分析的手段去探究真相。接下來將以訊息同步傳送為例揭示其訊息傳送處理流程中的核心關鍵點。

MQ Client 訊息傳送端首先會利用網路通道將請求傳送到 Broker，然後接收到請求結果後並呼叫 processSendResponse 方法對響應結果進行解析，如下圖所示：

在這裡，RemotingCommand 的 code 為
RemotingSysResponseCode.SYSTEM_BUSY。

我們從 proccessSendResponse 方法中可以得知，如果 code 為 SYSTEM_BUSY，該方法會丟擲 MQBrokerException，響應 code 為 SYSTEM_BUSY，其錯誤描述為開頭部分的錯誤資訊。

那我們沿著該方法的呼叫鏈，可以找到其直接呼叫方為：DefaultMQProducerImpl 的 sendKernelImpl，我們重點考慮如果底層方法丟擲 MQBrokerException 該方法會如何處理。

其關鍵程式碼如下圖所示：

可以看出在 sendKernelImpl 方法中首先會捕捉異常，先執行註冊的鉤子函式，即就算執行失敗，對應的訊息傳送後置鉤子函式也會執行，然後再原封不動的將該異常向上丟擲。

sendKernelImpl 方法被 DefaultMQProducerImpl 的 sendDefaultImpl 方法呼叫，下面是其核心實現截圖：

從這裡可以看出 RocketMQ 訊息傳送高可用設計一個非常關鍵的點，重試機制，其實現是在 for 迴圈中使用 try catch 將 sendKernelImpl 方法包裹，就可以保證該方法丟擲異常後能繼續重試。從上文可知，如果 SYSTEM_BUSY 會丟擲 MQBrokerException，但發現只有上述幾個錯誤碼才會重試，因為如果不是上述錯誤碼，會繼續向外丟擲異常，此時 for 迴圈會被中斷，即不會重試。

這裡非常令人意外的是連 SYSTEM_ERROR 都會重試，卻沒有包含 SYSTEM_BUSY，顯然違背了快速失敗的設計初衷，故筆者斷定，這是 RocketMQ 的一個BUG，將 SYSTEM_BUSY 遺漏了，後面與 RocketMQ 核心成員進行過溝通，也印證了這點，後續會提一個PR，在上面增加一行程式碼，將 SYSTEM_BUSY 加上即可。

問題分析到這裡，該問題應該就非常明瞭。

3、解決方案

如果大家在網上搜尋 TIMEOUT_CLEAN_QUEUE 的解決方法，大家不約而同提出的解決方案是增加 waitTimeMillsInSendQueue 的值，該值預設為200ms，例如將其設定為1000s等等，以前我是反對的，因為我的認知裡 Broker 會重試，但現在發現 Broker 不會重試，故提高該值能有效的緩解。

但這是並不是好的解決方案，我會在近期向官方提交一個PR，將這個問題修復，建議大家在公司儘量對自己使用的版本進行修改，重新打一個包即可，因為這已經違背了 Broker 端快速失敗的設計初衷。

但在訊息傳送的業務方，儘量自己實現訊息的重試機制，即不依賴 RocketMQ 本身提供的重試機制，因為受制與網路等因素，訊息傳送不可能百分之百成功，建議大家在訊息傳送時捕獲一下異常，如果傳送失敗，可以將訊息存入資料庫，再結合定時任務對訊息進行重試，盡最大程度保證訊息不丟失。