RocketMQ特性及面試（上)

1、順序消息

RocketMQ 經過本身的方式解決了消息順序性的問題：
RocketMQ經過輪詢全部隊列的方式來肯定消息被髮送到哪個隊列（負載均衡策略）。根據不一樣業務，能夠將業務ID做爲計算隊列，讓業務ID相同的消息前後發送到同一個隊列中，在獲取到路由信息之後，會根據MessageQueueSelector實現的算法來選擇一個隊列，同一個OrderId獲取到的確定是同一個隊列。

2、消息重複

在網絡不穩定的狀況下，RocketMQ會出現消息重複的問題：

發送時消息重複

• 當一條消息已被成功發送到服務端並完成持久化，此時出現了網絡閃斷或者客戶端宕機，致使服務端對客戶端應答失敗。 若是此時生產者意識到消息發送失敗並嘗試再次發送消息，消費者後續會收到兩條內容相同而且 Message ID 也相同的消息。

投遞時消息重複

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

負載均衡時消息重複

• 當消息隊列 RocketMQ 的 Broker 或客戶端重啓、擴容或縮容時，會觸發 Rebalance，此時消費者可能會收到重複消息。

形成消息重複的根本緣由是：網絡不可達。只要經過網絡交換數據，就沒法避免這個問題。 因此解決這個問題的辦法就是繞過這個問題。那麼問題就變成了：若是消費端收到兩條同樣的消息，應該怎樣處理？

1. 消費端處理消息的業務邏輯保持冪等性
2. 保證每條消息都有惟一編號且保證消息處理成功與去重表的日誌同時出現

第1條很好理解，只要保持冪等性，無論來多少條重複消息，最後處理的結果都同樣。
第2條原理就是利用一張日誌表來記錄已經處理成功的消息的ID，若是新到的消息ID已經在日誌表中，那麼就再也不處理這條消息。
第1條解決方案，很明顯應該在消費端實現，不屬於消息系統要實現的功能。
第2條能夠消息系統實現，也能夠業務端實現。正常狀況下出現重複消息的機率其實很小，若是由消息系統來實現的話，確定會對消息系統的吞吐量和高可用有影響，因此最好仍是由業務端本身處理消息重複的問題，這也是RocketMQ不解決消息重複的問題的緣由。

RocketMQ不保證消息不重複，若是你的業務須要保證嚴格的不重複消息，須要你本身在業務端去重。

那業務端如何去重呢？原理很簡單，步驟以下：

1. 記錄下每一個消息的msgID
2. 新消息來的時候，查看該消息的msgID是否已記錄，是則拋棄，不然消費 而後將msgID 存入緩存中，若是當再有此消息發送過來，查看redis中是否存在鍵值，如存在，則對此消息不進行處理。

3、事務消息

3.1 概念介紹

事務消息：消息隊列 RocketMQ 提供相似 X/Open XA 的分佈事務功能，經過消息隊列 RocketMQ 事務消息能達到分佈式事務的最終一致。 半消息：暫不能投遞的消息，發送方已經將消息成功發送到了消息隊列 RocketMQ 服務端，可是服務端未收到生產者對該消息的二次確認，此時該消息被標記成「暫不能投遞」狀態，處於該種狀態下的消息即半消息。 消息回查：因爲網絡閃斷、生產者應用重啓等緣由，致使某條事務消息的二次確認丟失，消息隊列 RocketMQ 服務端經過掃描發現某條消息長期處於「半消息」時，須要主動向消息生產者詢問該消息的最終狀態（Commit 或是 Rollback），該過程即消息回查。

3.2 適用場景

事務消息的適用場景示例： 經過購物車進行下單的流程中，用戶入口在購物車系統，交易下單入口在交易系統，兩個系統之間的數據須要保持最終一致，這時能夠經過事務消息進行處理。交易系統下單以後，發送一條交易下單的消息到消息隊列 RocketMQ，購物車系統訂閱消息隊列 RocketMQ 的交易下單消息，作相應的業務處理，更新購物車數據。

3.3 使用方式

交互流程

消息隊列 RocketMQ 事務消息交互流程以下所示： 事務消息

其中：

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

說明：事務消息發送對應步驟 一、二、三、4，事務消息回查對應步驟 五、六、7。

3.4 注意事項

1. 事務消息的 Group ID 不能與其餘類型消息的 Group ID 共用。與其餘類型的消息不一樣，事務消息有回查機制，回查時消息隊列 RocketMQ 服務端會根據 Group ID 去查詢客戶端。
2. 經過 ONSFactory.createTransactionProducer 建立事務消息的 Producer 時必須指定 LocalTransactionChecker 的實現類，處理異常狀況下事務消息的回查。
3. 事務消息發送完成本地事務後，可在 execute 方法中返回如下三種狀態：
   • TransactionStatus.CommitTransaction 提交事務，容許訂閱方消費該消息。
   • TransactionStatus.RollbackTransaction 回滾事務，消息將被丟棄不容許消費。
   • TransactionStatus.Unknow 暫時沒法判斷狀態，期待固定時間之後消息隊列 RocketMQ 服務端向發送方進行消息回查。
4. 可經過如下方式給每條消息設定第一次消息回查的最快時間：

Message message = new Message();
 // 在消息屬性中添加第一次消息回查的最快時間，單位秒。例如，如下設置實際第一次回查時間爲 120 秒 ~ 125 秒之間
 message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,"120");
// 以上方式只肯定事務消息的第一次回查的最快時間，實際回查時間向後浮動0~5秒；如第一次回查後事務仍未提交，後續每隔5秒回查一次。
複製代碼

4、Producer如何發送消息

4.1 可靠同步發送

同步發送是指消息發送方發出數據後，會在收到接收方發回響應以後才發下一個數據包的通信方式。

應用場景：此種方式應用場景很是普遍，例如重要通知郵件、報名短信通知、營銷短信系統等。

4.2 可靠異步發送

異步發送是指發送方發出數據後，不等接收方發回響應，接着發送下個數據包的通信方式。 MQ 的異步發送，須要用戶實現異步發送回調接口（SendCallback）。消息發送方在發送了一條消息後，不須要等待服務器響應便可返回，進行第二條消息發送。發送方經過回調接口接收服務器響應，並對響應結果進行處理。

應用場景：異步發送通常用於鏈路耗時較長，對 RT 響應時間較爲敏感的業務場景，例如用戶視頻上傳後通知啓動轉碼服務，轉碼完成後通知推送轉碼結果等。

4.3 單向（Oneway）發送

單向（Oneway）發送特色爲發送方只負責發送消息，不等待服務器迴應且沒有回調函數觸發，即只發送請求不等待應答。 此方式發送消息的過程耗時很是短，通常在微秒級別。

應用場景：適用於某些耗時很是短，但對可靠性要求並不高的場景，例如日誌收集。 下表歸納了三者的特色和主要區別。

4.4 三種方式比較

5、消息實時性

RocketMQ採起長輪詢+PULL模式保證消息的持久性

6、消息訂閱

消息隊列 RocketMQ 支持如下兩種訂閱方式：

集羣訂閱：同一個 Group ID 所標識的全部 Consumer 平均分攤消費消息。 例如某個 Topic 有 9 條消息，一個 Group ID 有 3 個 Consumer 實例，那麼在集羣消費模式下每一個實例平均分攤，只消費其中的 3 條消息。

// 集羣訂閱方式設置（不設置的狀況下，默認爲集羣訂閱方式）
 properties.put(PropertyKeyConst.MessageModel, PropertyValueConst.CLUSTERING);
複製代碼

廣播訂閱：同一個 Group ID 所標識的全部 Consumer 都會各自消費某條消息一次。 例如某個 Topic 有 9 條消息，一個 Group ID 有 3 個 Consumer 實例，那麼在廣播消費模式下每一個實例都會各自消費 9 條消息。

// 廣播訂閱方式設置
 properties.put(PropertyKeyConst.MessageModel, PropertyValueConst.BROADCASTING);
複製代碼

7、定時消息和延時消息

• 定時消息：Producer 將消息發送到消息隊列 RocketMQ 服務端，但並不指望這條消息立馬投遞，而是推遲到在當前時間點以後的某一個時間投遞到 Consumer 進行消費，該消息即定時消息。
• 延時消息：Producer 將消息發送到消息隊列 RocketMQ 服務端，但並不指望這條消息立馬投遞，而是延遲必定時間後才投遞到 Consumer 進行消費，該消息即延時消息。

定時消息與延時消息在代碼配置上存在一些差別，可是最終達到的效果相同：消息在發送到消息隊列 RocketMQ 服務端後並不會立馬投遞，而是根據消息中的屬性延遲固定時間後才投遞給消費者。

定時消息和延時消息適用於如下一些場景：

• 消息生產和消費有時間窗口要求：好比在電商交易中超時未支付關閉訂單的場景，在訂單建立時會發送一條 延時消息。這條消息將會在 30 分鐘之後投遞給消費者，消費者收到此消息後須要判斷對應的訂單是否已完成支付。 如支付未完成，則關閉訂單。如已完成支付則忽略。
• 經過消息觸發一些定時任務，好比在某一固定時間點向用戶發送提醒消息。