說明

RocketMQ叢集消費的時候，我們經常看到類似註釋裡面 （1，（2 的寫法，已經有時候有同學沒注意拋異常的情況就是（3 模擬的情況。那麼這3種情況到底是怎麼樣的呢？你是否都瞭然於心呢？下面我們一起來看看吧，本文主要在講解RocketMQ叢集消費有些內容會提到但是不會深入講解（以後有機會講其他的）。

RocketMQ叢集消費執行過程

雖然說是PushConsumer其實本質還是拉。

再跟進去

在繼續跟進

Netty推薦使用addListener的方式來回調非同步執行的結果。，關於opaque這個在RocketMQ(二)：RPC通訊詳細說明了。

當到broker拉取的資料返回之後：

獲取到拉請求的時候存入的opaque。執行非同步回撥：

到這裡開始執行消費情況了。

消費提交執行緒池。

到這裡就到了真正執行消費端程式碼了，就是我們最開始的這個程式碼了：

分析

由於有3種情況，那麼重點就在下面這個status這行程式碼了。

就是最開始討論的三種情況了，staus的值就對應(1 (2 (3 情況了。

(1 ==》成功，status 就是成功狀態

(2 ==》重試，status就是重試狀態

(3 ==》null，拋異常了，status最終還是會被標記為重試狀態

備註：RocketMQ最佳實踐，不建議拋異常，而建議返回重試狀態。

關鍵就在於分析這塊了。

其實如果批消費400條，假如前399條都成功了，最後一條失敗，返回重試的話，這400條都會發送bak到broker上面的，值得注意，並不是理所當然的那種就最後一條重試。

關於RPC這塊，建議看看RocketMQ(二)：RPC通訊，我們看看broker端的處理：

進行跟進

消費端傳送bak過來的delayLevel都是0，重新根據消費次數+3設定，之後把消費次數+1，之後進行儲存訊息。

後面儲存就和正常存在一樣了，那麼訊息怎麼再次投遞呢？ 如果一直投遞怎麼可能？

每重試一次reconsumeTimes都會+1，一直到16次（預設）

會放到DLQ死信佇列。

定時訊息由於涉及到內容太多，準備下次分享。

結論

通過上面分析，應該可以明白RocketMQ叢集消費的大體邏輯以及執行情況，以及最佳實踐，並且知道了如果一批消費n（n>1）,如果最後有一條消費失敗，導致傳送了消費重試，那麼這n條都會進行重試的。

文章github原始碼地址：rocketmq，或者公號回覆“rocketmq”獲取原始碼地址。

如果讀完覺得有收穫的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！