面試連環(huán)炮系列（二十?五）：RocketMQ怎么保證消息不丟失

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

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

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

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

• D. 從Producer分析：如何確保消息正確的發(fā)送到了Broker?

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

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

RocketMQ支持日志的索引，如果一條消息發(fā)送之后超時，也可以通過查詢?nèi)罩镜腁PI，來check是否在Broker存儲成功。

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

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

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

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

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

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

絕大多數(shù)情況下，消息是不重復的。在網(wǎng)絡抖動、應用處理超時等異常情況下，無法保證消息不重復，但是能保證消息不丟失。消息重復分兩種情況：

• 發(fā)送時消息重復

當一條消息已被成功發(fā)送到服務端并完成持久化，此時出現(xiàn)了網(wǎng)絡閃斷或者客戶端宕機，導致服務端對客戶端應答失敗。如果此時生產(chǎn)者意識到消息發(fā)送失敗并嘗試再次發(fā)送消息，消費者后續(xù)會收到兩條內(nèi)容相同并且 Message ID 也相同的消息。

• 投遞時消息重復

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

正常情況下出現(xiàn)重復消息的概率小，如果RocketMQ實現(xiàn)判重的話，肯定會降低吞吐量和高可用，最好由業(yè)務端自己處理重復消息。

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

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

4. RocketMQ可以是實現(xiàn)順序消息嗎？

順序消息是指哪條消息先進入，哪條消息就會先被消費，符合FIFO。RocketMQ支持順序消息，又分為分區(qū)順序和全局順序。全局順序其實是分區(qū)順序的一個特例，即使Topic只有一個分區(qū)。全局順序?qū)⒚媾R性能的問題，而且絕大多數(shù)場景都不需要全局順序。

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

• 消息被發(fā)送時保持順序
  用戶在同一個線程中采用同步的方式發(fā)送消息。

• 消息被存儲時保持和發(fā)送的順序一致
  Producer端確保消息順序唯一要做的事情就是將消息路由到特定的分區(qū)，在RocketMQ中，通過MessageQueueSelector來實現(xiàn)分區(qū)的選擇。

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

• List mqs：消息要發(fā)送的Topic下所有的分區(qū)
• Message msg：消息對象
• 額外的參數(shù)：用戶可以傳遞自己的參數(shù)

如下實現(xiàn)就可以保證相同的訂單的消息被路由到相同的分區(qū)：

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

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

RocketMQ消費端有兩種類型：MQPullConsumer和MQPushConsumer。

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

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

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

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

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