一. 消息發送重試
生產者在發送消息時，同步消息失敗會重投，異步消息有重試，oneway沒有任何保證。消息重投保證消息儘可能發送成功、不丟失，但可能會造成消息重複發送。消息重複發送在一般情況下不會發生，當出現消息量大、網絡抖動，就會大概率出現。另外，生產者主動重發、consumer負載變化也會導致重複消息。如下方法可以設置消息重試策略：
- retryTimesWhenSendFailed: 同步發送失敗重投次數，默認爲2，因此生產者最多會嘗試發送retryTimesWhenSendFailed + 1次。且生產者不會選擇上次失敗的broker，而是嘗試向其他broker發送，最大程度保證消息不丟。超過重投次數，拋出異常，由客戶端保證消息不丟。當出現RemotingException、MQClientException和部分MQBrokerException時會重投。
- retryTimesWhenSendAsyncFailed: 異步發送失敗重試次數，異步重試不會選擇其他broker，僅在同一個broker上做重試，不保證消息不丟（導致broker掛掉後消息一直無法發送出去）。
- retryAnotherBrokerWhenNotStoreOK: 消息刷盤（主或備）超時或slave不可用（返回狀態非SEND_OK），是否嘗試發送到其他broker，默認false。十分重要消息可以開啓。
二. 消息消費重試
Consumer消費消息失敗後，要提供一種重試機制，令消息再消費一次。Consumer消費消息失敗通常可以認爲有以下幾種情況：
- 由於消息本身的原因，例如反序列化失敗，消息數據本身無法處理等。這種錯誤通常需要跳過這條消息，再消費其它消息，而這條失敗的消息即使立刻重試消費，99%也不成功，所以最好提供一種定時重試機制，即過10秒後再重試。
- 由於依賴的下游應用服務不可用，例如db連接不可用，外系統網絡不可達等。遇到這種錯誤，即使跳過當前失敗的消息，消費其他消息同樣也會報錯。這種情況建議應用sleep 30s，再消費下一條消息，這樣可以減輕Broker重試消息的壓力
三. 重試隊列
- 考慮到異常恢復起來需要一些時間，會爲重試隊列設置多個重試級別，每個重試級別都有與之相應的重投延時，重試次數越多投遞延時就越大。RocketMQ對於重試消息的處理是先保存至Topic名稱爲“SCHEDULE_TOPIC_XXXX”的延遲隊列中，後臺定時任務按照對應的時間進行延時後重新投遞至"%RETRY%+consumerGroup"重試隊列中。
- RocketMQ會爲每個消費組設置一個Topic名稱爲"%RETRY%+consumerGroup"的重試隊列（這裏需要注意的是，這個Topic的重試隊列是針對消費者組的，而不是針對每個Topic設置的），用於暫時保存因爲各種異常而導致Consumer端無法消費的消息
- 延時級別
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h