說明
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”獲取源碼地址。
如果讀完覺得有收獲的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！
