RocketMQ集羣消費的那些事

說明

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」獲取源碼地址。

---

若是讀完以爲有收穫的話，歡迎點贊、關注、加公衆號【匠心零度】，查閱更多精彩歷史！！！