RocketMQ如何保證消息的可靠性？
消息的發送方式有哪幾種?存儲消息的可靠性面臨哪些挑戰?消費消息的確認機制是怎樣的?本文通過分析消息流轉的整個過程，從消息發送、消息存儲和消息消費三個階段介紹RocketMQ是如何保證消息的可靠性的。
分布式系統中一個重要的前提假設是所有的網絡傳輸都是不可靠的，在網絡傳輸不可靠的情況下，保證消息的可靠傳輸，除了進行重試投遞別無他法。常用的絕大多數消息隊列RocketMQ、RabbitMQ等在消息傳輸上都只能保證至少傳輸成功一次，也即(At least once)，而不能保證只傳輸成功一次(Exactly once)。由于分布式系統網絡的不可靠，可能就會出現消息丟失的現象，那么RocketMQ是如何最大限度的保證消息不丟失的呢?那就需要從消息的產生到最終消費的整個過程來分析，消息完整鏈路可以劃分為以下三個階段：
- 生產階段：消息在 Producer 發送端創建出來，經過網絡傳輸發送到 Broker 存儲端。
- 存儲階段：消息在 Broker 端存儲，如果是主備或者多副本，消息會在這個階段被復制到其他的節點或者副本上。
- 消費階段：Consumer 消費端從 Broker存儲端拉取消息，經過網絡傳輸發送到 Consumer 消費端上，并通過重試來最大限度的保證消息的消費。
一 發送端消息可靠性
發送端Producer發送消息Broker端的核心邏輯如下圖所示：
消息發送一般有以下幾種方式：同步發送、異步發送以及單向發送，業務具體選擇哪種方式進行消息發送，需要根據情況進行判斷，下面具體介紹不同的發送方式實現的消息可靠性保證。
1 同步發送
同步發送是指發送端在發送消息時，阻塞線程進行等待，直到服務器返回發送的結果。發送端如果需要保證消息的可靠性，防止消息發送失敗，可以采用同步阻塞式的發送，然后同步檢查Brocker返回的狀態來判斷消息是否持久化成功。如果發送超時或者失敗，則會默認重試2次，RocketMQ選擇至少傳輸成功一次的消息模型，但是有可能發生重復投遞，因為網絡傳輸是不可靠的，具體的重試策略可以參照第四小節。
2 異步發送
異步發送是指發送端在發送消息時，傳入回調接口實現類，調用該發送接口后不會阻塞，發送方法會立即返回，回調任務會在另一個線程中執行，消息發送結果會回傳給相應的回調函數。具體的業務實現可以根據發送的結果信息來判斷是否需要重試來保證消息的可靠性。
3 單向發送
單向發送是指發送端發送完成之后，調用該發送接口后立刻返回，并不返回發送的結果，業務方無法根據發送的狀態來判斷消息是否發送成功，單向發送相對前兩種發送方式來說是一種不可靠的消息發送方式，因此要保證消息發送的可靠性，不推薦采用這種方式來發送消息。
4 發送重試策略
RocketMQ架構模型中會有多個Borker為某個topic提供服務，一個topic下的消息分散存儲在多個Broker存儲端，它們是多對多關系。Broker會將其提供存儲服務的topic的元數據信息上報到NameServer，對等NameServer節點組成的高可用服務會維護topic與Broker之間的映射關系，多對多的映射關系為消息可以重試發送到多個Broker端提供了前提與基礎。
當發送端需要發送消息時，如果發送端中緩存了topic的路由信息，并包含了消息隊列,則直接返回該路由信息,如果沒有緩存或沒有消息隊列，則向NameServer查詢該topic的路由信息，查詢到路由消息之后，采用指定的隊列選擇策略選擇相應的queue發送消息，默認是采用輪詢策略，發送成功則返回, 收到異常則根據相應的策略進行重試，可以根據發送端感知到的Broker的時延、上次發送失敗的Broker信息和發送端配置的是否重試不同Broker的參數以及發送端設置的最大超時時間等等策略來靈活地實現不同等級的消息發送可靠性保證。重試策略可以有效的保證消息發送成功的概率，最終提高消息發送的可靠性。
二 存儲端消息可靠性
RocketMQ的消息存儲結構如下圖所示：
- 消息隊列存儲的最小單位是消息Message。
- 同一個Topic下的消息映射成多個邏輯隊列。
- 不同Topic的消息按照到達broker的先后順序以Append的方式添加至CommitLog，順序寫，隨機讀。
目前RocketMQ存儲模型使用本地磁盤進行存儲，數據寫入為producer -> direct memory -> pagecache -> 磁盤，數據讀取如果pagecache有數據則直接從pagecache讀，否則需要先從磁盤加載到pagecache中。Broker存儲節點的文件存儲模式如下圖所示：
Broker端CommitLog采用順序寫，可以大大提高寫入效率，同時采用不同的刷盤模式提供不同的數據可靠性保證，此外采用了ConsumeQueue中間結構來存儲偏移量信息，實現消息的分發。由于ConsumeQueue結構固定且大小有限，在實際情況中，大部分的ConsumeQueue 能夠被全部讀入內存，可以達到內存讀取的速度。此外為了保證CommitLog和ConsumeQueue的一致性， CommitLog里存儲了Consume Queues 、Message Key、Tag等所有信息，即使ConsumeQueue丟失，也可以通過 commitLog完全恢復出來，這樣只要保證commitLog數據的可靠性，就可以保證Consume Queue的可靠性。
RocketMQ存儲端采用本地磁盤進行CommitLog消息數據的存儲，不可避免的就會帶來存儲可靠性的挑戰，如何保證消息不丟失，RocketMQ消息服務一直在不斷提高數據的可靠性。
1 存儲可靠性挑戰
RocketMQ存儲端也即Broker端在存儲消息的時候會面臨以下的存儲可靠性挑戰：
- Broker正常關閉
- Broker異常Crash
- OS Crash
- 機器掉電，但是能立即恢復供電情況
- 機器無法開機(可能是cpu、主板、內存等關鍵設備損壞)
- 磁盤設備損壞
1正常關閉，Broker 可以正常啟動并恢復所有數據。2、3、4同步刷盤可以保證數據不丟失，異步刷盤可能導致少量數據丟失。5、6屬于單點故障，且無法恢復。解決單點故障可以采用增加Slave節點，主從異步復制仍然可能有極少量數據丟失，同步復制可以完全避免單點問題。
這里一般來說就需要在性能和可靠性之間做出取舍，對于RocketMQ來說，Broker的可靠性主要由兩個方面保障：
- 單機的刷盤機制
- 主從之間的數據復制
如果設置為每條消息都強制刷盤、主從復制，那么性能無疑會降低;如果不這樣設置，就會有一定的可能性丟失消息。RocketMQ一般都是先把消息寫到PageCache中，然后再持久化到磁盤上，數據從pagecache刷新到磁盤有兩種方式，同步和異步。整體的消息寫入和讀取如下圖所示：
針對broker端單機存儲可靠性，主要依賴單機的刷盤策略，主從之間的副本復制可以參考下一章節的主從模式。
2 同步刷盤
消息寫入內存的 PageCache后，立刻通知刷盤線程刷盤，然后等待刷盤完成，刷盤線程執行完成后喚醒等待的線程，返回消息寫成功的狀態。這種方式可以保證數據絕對安全，但是吞吐量不大。
3 異步刷盤(默認)
消息寫入到內存的 PageCache中，就立刻給客戶端返回寫操作成功，當 PageCache中的消息積累到一定的量時，觸發一次寫操作，或者定時等策略將 PageCache中的消息寫入到磁盤中。這種方式吞吐量大，性能高，但是 PageCache中的數據可能丟失，不能保證數據絕對的安全。
實際應用中要結合業務場景，合理設置刷盤方式，尤其是同步刷盤的方式，由于頻繁的觸發磁盤寫動作，會明顯降低性能。
4 過期文件刪除
由于RocketMQ操作CommitLog、ConsumeQueue文件是基于文件內存映射機制，并且在啟動的時候會將所有的文件加載，為了避免內存與磁盤的浪費、能夠讓磁盤能夠循環利用、避免因為磁盤不足導致消息無法寫入等引入了文件過期刪除機制。最終使得磁盤水位保持在一定水平，最終保證新寫入消息的可靠存儲。
三 消費端消息可靠性
RockerMQ默認提供了至少消費一次的消費語義來保證消息的可靠消費。
通常消費消息的確認機制一般分為兩種思路：
- 先提交后消費
- 先消費，消費成功后再提交
思路1可以解決重復消費的問題但是會丟失消息，因此RocketMQ默認實現的是思路2，由各自consumer業務方保證冪等來解決重復消費問題。
消費端Consumer消費消息核心邏輯如下圖所示：
1 消費重試
消費者從RocketMQ拉取到消息之后，需要返回消費成功來表示業務方正常消費完成。因此只有返回CONSUME_SUCCESS才算消費完成，如果返回CONSUME_LATER則會按照不同的messageDelayLevel時間進行再次消費，時間分級從秒到小時，最長時間為2個小時后再次進行消費重試，如果消費滿16次之后還是未能消費成功，則不再重試，會將消息發送到死信隊列，從而保證消息存儲的可靠性。
2 死信隊列
未能成功消費的消息，消息隊列并不會立刻將消息丟棄，而是將消息發送到死信隊列，其名稱是在原隊列名稱前加%DLQ%，如果消息最終進入了死信隊列，則可以通過RocketMQ提供的相關接口從死信隊列獲取到相應的消息，保證了消息消費的可靠性。
3 消息回溯
回溯消費是指Consumer已經消費成功的消息，或者之前消費業務邏輯有問題，現在需要重新消費。要支持此功能，則Broker存儲端在向Consumer消費端投遞成功消息后，消息仍然需要保留。重新消費一般是按照時間維度，例如由于Consumer系統故障，恢復后需要重新消費1小時前的數據。RocketMQ Broker提供了一種機制，可以按照時間維度來回退消費進度，這樣就可以保證只要發送成功的消息，只要消息沒有過期，消息始終是可以消費到的。
四 總結
本文從消息流轉的整個過程分析了RocketMQ如何保證消息的可靠性，消息發送通過不同的重試策略保證了消息的可靠發送，消息存儲通過不同的刷盤機制以及多副本來保證消息的可靠存儲，消息消費通過至少消費成功一次以及消費重試機制來保證消息的可靠消費，RocketMQ在保證消息的可靠性上做到了全鏈路閉環，最大限度的保證了消息不丟失。
