- 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之前的消息到本地。
- RocketMQ如何保證消息不重復？
絕大多數情況下，消息是不重復的。在網絡抖動、應用處理超時等異常情況下，無法保證消息不重復，但是能保證消息不丟失。消息重復分兩種情況：
- 發送時消息重復
當一條消息已被成功發送到服務端並完成持久化，此時出現了網絡閃斷或者客戶端宕機，導致服務端對客戶端應答失敗。如果此時生產者意識到消息發送失敗並嘗試再次發送消息，消費者后續會收到兩條內容相同並且 Message ID 也相同的消息。
- 投遞時消息重復
消息消費的場景下，消息已投遞到消費者並完成業務處理，當客戶端給服務端反饋應答的時候網絡閃斷。為了保證消息至少被消費一次，消息隊列 RocketMQ的服務端將在網絡恢復后再次嘗試投遞之前已被處理過的消息，消費者后續會收到兩條內容相同並且 Message ID 也相同的消息。
正常情況下出現重復消息的概率小，如果RocketMQ實現判重的話，肯定會降低吞吐量和高可用，最好由業務端自己處理重復消息。
- 消費端收到兩條一樣的消息，應該怎樣處理
消費端按業務唯一標識保持業務處理冪等性。只要保持冪等性，不管來多少條重復消息，最后處理的結果都一樣。
- 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自然和存儲順序一致，用戶需要再拿到這批消息后自己保證消費的順序。
- 使用順序消息存在哪些問題？
- 需要有順序關系的消息發送到同一個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