初步瞭解消息失敗重試機制消息失敗，無非涉及到2端：從生產者端發往MQ的失敗；消費者端從MQ消費消息的失敗；生產者端的失敗重試
生產者端失敗重試
生產者端的消息失敗：比如網絡抖動導致生產者發送消息到MQ失敗。
上圖代碼示例的處理手段是：如果該條消息在1S內沒有發送成功，那麼重試3次。
消費者端的失敗重試
消費者端的失敗，分爲2種情況，一個是timeout，一個是exception
timeout，比如由於網絡原因導致消息壓根就沒有從MQ到消費者上，在RocketMQ內部會不斷的嘗試發送這條消息，直至發送成功爲止！（比如集羣中一個broker失敗，就嘗試另一個broker）
exception，消息正常的到了消費者，結果消費者發生異常，處理失敗了。這裏涉及到一些問題，需要我們思考下，比如，消費者消費消息的狀態有哪些定義？如果失敗，MQ將採取什麼策略進行重試？假設一次性批量PUSH了10條，其中某條數據消費異常，那麼消息重試是10條呢，還是1條呢？而且在重試的過程中，需要保證不重複消費嗎？
ConsumeConcurrentlyStatus
消息消費的狀態，有2種，一個是成功（CONSUME_SUCCESS），一個是失敗&稍後重試（RECONSUME_LATER）
broker啓動日誌
在啓動broker的過程中，可以觀察下日誌，你會發現RECONSUME_LATER的策略。
如果消費失敗，那麼1S後再次消費，如果失敗，那麼5S後，再次消費，…直至2H後如果消費還失敗，那麼該條消息就會終止發送給消費者了！
RocketMQ爲我們提供了這麼多次數的失敗重試，但是在實際中也許我們並不需要這麼多重試，比如重試3次，還沒有成功，我們希望把這條消息存儲起來並採用另一種方式處理，而且希望RocketMQ不要在重試呢，因爲重試解決不了問題了！這該如何做呢？
我們先來看一下一條消息MessageExt對象的輸出：MessageExt [queueId=0, storeSize=137, queueOffset=0, sysFlag=0, bornTimestamp=1492213846916, bornHost=/192.168.99.219:50478, storeTimestamp=1492213846981, storeHost=/192.168.99.121:10911, msgId=C0A8637900002A9F0000000000000000, commitLogOffset=0, bodyCRC=613185359, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message [topic=TopicTest2, flag=0, properties={TAGS=TagA, WAIT=true, MAX_OFFSET=3, MIN_OFFSET=0}, body=16]]注意到reconsumeTimes屬性，這個屬性就代表消息重試的次數！來看一段代碼：
reconsumeTime的使用
注意了，對於消費消息而言，存在2種指定的狀態（成功 OR 失敗重試），如果一條消息在消費端處理沒有返回這2個狀態，那麼相當於這條消息沒有達到消費者，勢必會再次發送給消費者！也即是消息的處理必須有返回值，否則就進行重發。
作者：張豐哲
鏈接：https://www.jianshu.com/p/790d6bc4a1c1
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。