rocketmq 面試（1）

rocketmq topic圖解：

1.Rocketmq怎麼保證消息的有序性？

生產者端處理： Producer端發送時，指定MessageSelector，算出將消息放到哪個queue

消費端處理： 如何保證消費端 順序消費？ 如果是使用MessageListenerOrderly(**順序消費)**則自帶順序消費實現，如果是使用MessageListenerConcurrently（併發消費），則需要把線程池改爲單線程模式。

MessageListenerOrderly(順序消費)：有序消費，同一隊列的消息同一時刻只能一個線程消費，可保證消息在同一隊列嚴格有序消費
MessageListenerConcurrently（併發消費）：

2.Rocketmq怎麼保證消息一定可達，不丟失？

1. 怎麼保證Producer發送消息階段不丟失？
   rocketmq提供了三種方式發送消息
   
   同步發送： Producer 向 broker 發送消息，阻塞當前線程等待 broker 響應 發送結果。
   異步發送： Producer 首先構建一個向 broker 發送消息的任務，把該任務提交給線程池，等執行完該任務時，回調用戶自定義的回調函數，執行處理結果。
   Oneway發送： Oneway 方式只負責發送請求，不等待應答，Producer 只負責把請求發出去，而不處理響應結果。
   我們使用同步發送返送，並且捕獲返回結果進行重試，可以減小消息發送丟失。

2. 怎麼保證Conusmer消費消息不丟失？
   PushConsumer爲了保證消息肯定消費成功，只有使用方明確表示消費成功，RocketMQ纔會認爲消息消費成功。中途斷電，拋出異常等都不會認爲成功——即都會重新投遞。
   ConsumeConcurrentlyStatus.CONSUME_SUCCESS

3. 怎麼保證brocker存儲消息不丟失？
   採用同步刷盤模式，當刷盤成功後才返回producer投遞消息成功。

3.怎麼保證最終一致性？

事務消息

1. 發送方向 MQ 服務端發送消息。
2. MQ Server 將消息持久化成功之後，向發送方 ACK 確認消息已經發送成功，此時消息爲半消息。
3. 發送方開始執行本地事務邏輯。
4. 發送方根據本地事務執行結果向 MQ Server 提交二次確認（Commit 或是 Rollback），MQ Server 收到Commit 狀態則將半消息標記爲可投遞，訂閱方最終將收到該消息；MQ Server 收到 Rollback 狀態則刪除半消息，訂閱方將不會接受該消息。
5. 在斷網或者是應用重啓的特殊情況下，上述步驟4提交的二次確認最終未到達 MQ Server，經過固定時間後MQ Server 將對該消息發起消息回查。
6. 發送方收到消息回查後，需要檢查對應消息的本地事務執行的最終結果。
7. 發送方根據檢查得到的本地事務的最終狀態再次提交二次確認，MQ Server 仍按照步驟4對半消息進行操作。

Producer Group
標識發送同一類消息的Producer，通常發送邏輯一致。發送普通消息的時候，僅標識使用，並無特別用處。若事務消息，如果某條發送某條消息的producer-A宕機，使得事務消息一直處於PREPARED狀態並超時，則broker會回查同一個group的其 他producer，確認這條消息應該commit還是rollback。但開源版本並不支持事務消息。

4.consumer的消費模式？

1. 廣播消費
   廣播消費是指一個consumer只要訂閱了某個topic的消息，那它就會收到該topic下的所有queue裏的消息，而不管這個consumer的group是什麼。所以對於廣播消費來說，consumer group沒什麼實際意義

consumer.setMessageModel(MessageModel.BROADCASTING)

2. 集羣消費
   集羣消費是指，一個consumer group下的consumer，平均消費topic下的queue。假如一個topic下有4個queue，然後當前有一個consumer group，該分組下有4個consumer，那每個consumer就被分配到該topic下的一個queue，這樣就達到了平均消費topic下的queue的目的。

 consumer.setMessageModel(MessageModel.CLUSTERING);