面試連環炮系列（二十?五）：RocketMQ怎么保證訊息不丟失

1. RocketMQ怎么保證訊息不丟失？

• A. 從Producer的視角來看：如果訊息未能正確的存盤在MQ中，或者消費者未能正確的消費到這條訊息，都是訊息丟失，

• B. 從Broker的視角來看：如果訊息已經存在Broker里面了，如何保證不會丟失呢（宕機、磁盤崩潰），

• C. 從Consumer的視角來看：如果訊息已經完成持久化了，但是Consumer取了，但是未消費成功且沒有反饋，就是訊息丟失，

• D. 從Producer分析：如何確保訊息正確的發送到了Broker?

默認情況下，可以通過同步的方式阻塞式的發送，check SendStatus，狀態是OK，表示訊息一定成功的投遞到了Broker，狀態超時或者失敗，則會觸發默認的2次重試，此方法的發送結果，可能Broker存盤成功了，也可能沒成功，

采取事務訊息的投遞方式，并不能保證訊息100%投遞成功到了Broker，但是如果訊息發送Ack失敗的話，此訊息會存盤在CommitLog當中，但是對ConsumerQueue是不可見的，可以在日志中查看到這條例外的訊息，嚴格意義上來講，也并沒有完全丟失，

RocketMQ支持日志的索引，如果一條訊息發送之后超時，也可以通過查詢日志的API，來check是否在Broker存盤成功，

從Broker分析：如果確保接收到的訊息不會丟失?

訊息支持持久化到Commitlog里面，即使宕機后重啟，未消費的訊息也是可以加載出來的Broker自身支持同步刷盤、異步刷盤的策略，可以保證接收到的訊息一定存盤在本地的記憶體中，

Broker集群支持1主N從的策略，支持同步復制和異步復制的方式，同步復制可以保證即使Master磁盤崩潰，訊息仍然不會丟失，

從Cunmser分析：如何確保拉取到的訊息被成功消費？

消費者可以根據自身的策略批量Pull訊息，Consumer自身維護一個持久化的offset（對應MessageQueue里面的min offset），標記已經成功消費或者已經成功發回到broker的訊息下標，如果Consumer消費失敗，那么它會把這個訊息發回給Broker，發回成功后，再更新自己的offset，如果Consumer消費失敗，發回給broker時，broker掛掉了，那么Consumer會定時重試這個操作，
如果Consumer和broker一起掛了，訊息也不會丟失，因為consumer里面的offset是定時持久化的，重啟之后，繼續拉取offset之前的訊息到本地，

2. RocketMQ如何保證訊息不重復？

絕大多數情況下，訊息是不重復的，在網路抖動、應用處理超時等例外情況下，無法保證訊息不重復，但是能保證訊息不丟失，訊息重復分兩種情況：

• 發送時訊息重復

當一條訊息已被成功發送到服務端并完成持久化，此時出現了網路閃斷或者客戶端宕機，導致服務端對客戶端應答失敗，如果此時生產者意識到訊息發送失敗并嘗試再次發送訊息，消費者后續會收到兩條內容相同并且 Message ID 也相同的訊息，

• 投遞時訊息重復

訊息消費的場景下，訊息已投遞到消費者并完成業務處理，當客戶端給服務端反饋應答的時候網路閃斷，為了保證訊息至少被消費一次，訊息佇列 RocketMQ的服務端將在網路恢復后再次嘗試投遞之前已被處理過的訊息，消費者后續會收到兩條內容相同并且 Message ID 也相同的訊息，

正常情況下出現重復訊息的概率小，如果RocketMQ實作判重的話，肯定會降低吞吐量和高可用，最好由業務端自己處理重復訊息，

3. 消費端收到兩條一樣的訊息，應該怎樣處理

消費端按業務唯一標識保持業務處理冪等性，只要保持冪等性，不管來多少條重復訊息，最后處理的結果都一樣，

4. RocketMQ可以是實作順序訊息嗎？

順序訊息是指哪條訊息先進入，哪條訊息就會先被消費，符合FIFO，RocketMQ支持順序訊息，又分為磁區順序和全域順序，全域順序其實是磁區順序的一個特例，即使Topic只有一個磁區，全域順序將面臨性能的問題，而且絕大多數場景都不需要全域順序，

在MQ的模型中，順序需要由3個階段去保障：

• 訊息被發送時保持順序
  用戶在同一個執行緒中采用同步的方式發送訊息，

• 訊息被存盤時保持和發送的順序一致
  Producer端確保訊息順序唯一要做的事情就是將訊息路由到特定的磁區，在RocketMQ中，通過MessageQueueSelector來實作磁區的選擇，

public interface MessageQueueSelector {
    MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);
}

• List mqs：訊息要發送的Topic下所有的磁區
• Message msg：訊息物件
• 額外的引數：用戶可以傳遞自己的引數

如下實作就可以保證相同的訂單的訊息被路由到相同的磁區：

long orderId = ((Order) object).getOrderId;
return mqs.get(orderId % mqs.size());

• 訊息被消費時保持和存盤的順序一致

RocketMQ消費端有兩種型別：MQPullConsumer和MQPushConsumer，

MQPullConsumer由用戶控制執行緒，主動從服務端獲取訊息，每次獲取到的是一個MessageQueue中的訊息，PullResult中的List msgFoundList自然和存盤順序一致，用戶需要再拿到這批訊息后自己保證消費的順序，

4. 使用順序訊息存在哪些問題？

• 需要有順序關系的訊息發送到同一個queue中，而不是使用客戶端自帶的負載均衡策略，所以一旦量比較大，可能會造成這個佇列訊息量很大，而其它佇列比較空閑的情況，
  順序訊息處理也必須在同一個consumer上，而且同一個queue的訊息只能單執行緒處理，也存在訊息堆積的可能，
  如果業務處理訊息失敗，只會在consumer端重試，到達重試次數之后，會直接放入broker中的死信佇列，
• 順序訊息無法保證100%訊息的順序，例如，有訊息m1，m2，m3需要順序處理，m1被發到q1中，這時候q1所在的broker宕機，Producer會另外選擇一個queue來投遞m2和m3，這個時候m1和m2會到達不同的consumer上，當然這種情況發生的概率是非常低的，因為producer從檢測到broker宕機到切換queue需要一段時間，同時consumer要有訊息堆積才會造成這種現象的出現，

參考(摘抄的文字著作權屬于原作者)：

https://blog.csdn.net/leeasony/article/details/104857576
https://blog.csdn.net/qq_38545713/article/details/104758104
https://www.jianshu.com/p/e1831c883e54
https://www.cnblogs.com/hzmark/p/orderly_message.html

標籤：其他

上一篇：日志管理系統，多種方式總結

下一篇：如何在C#中比較兩個日期的年、月、日、小時、分鐘、秒？