RocketMq實戰
RocketMq是阿里巴巴集團自主研發的專業訊息中介軟體。 產品基於高可用分散式叢集技術，提供訊息訂閱和釋出、訊息軌跡查詢、定時（延時）訊息、資源統計、監控報警等一系列訊息雲服務，是企業級網際網路架構的核心產品。
為分散式應用系統提供非同步解耦、削峰填谷的能力，同時具備海量訊息堆積、高吞吐、可靠重試等網際網路應用所需的特性
訊息型別
- 事務訊息：實現類似 X/Open XA 的分佈事務功能，以達到事務最終一致性狀態。
- 定時（延時）訊息：允許訊息生產者指定訊息進行定時（延時）投遞，最長支援 40 天。
- 大訊息：支援最大 4MB 訊息。
- 訊息軌跡：通過訊息軌跡，使用者能清晰定位訊息從釋出者發出，經由 MQ 服務端，投遞給訊息訂閱者的完整鏈路，方便定位排查問題。
- 廣播消費：允許一個 Consumer ID 所標識的所有 Consumer 都會各自消費某條訊息一次。
- 順序訊息：允許訊息消費者按照訊息傳送的順序對訊息進行消費。
- 重置消費進度：根據時間重置消費進度，允許使用者進行訊息回溯或者丟棄堆積訊息。
事務
為什麼會有事務，事務的應用場景是什麼？
假設有如下場景：
訂單支付完成後會做如下兩件事情：
- 修改訂單狀態（為核心系統處理）
- 通知使用者積分系統 增加積分（傳送至mq佇列消費，不佔用核心系統，做到非同步解耦），此過程處理失敗，不應該回滾正常訂單狀態
沒有事務的做法
假設沒有事務，我們通常的做法是在修改訂單狀態完成後，核心系統本地事務提交後，傳送mq訊息。
但是問題來了：假設傳送mq的時候核心系統宕機，mq訊息沒有傳送出去，那系統就無法處理積分，導致資訊丟失
增加事務
此時RocketMq的事務機制開始登場
核心為MQ傳送方來統籌傳送訊息、處理本地事務、檢查本地事務狀態。
跟沒有事務的做法最主要的區別就是，預先發送Half訊息，MqServer沒有得到傳送方的訊息會去回查事務狀態，從而保證事務的一致性。假設本地事務期間發生了異常，事務回滾，那麼訊息直接丟棄，如果在第4步發生異常，回查發現本地事務已提交，則Commit投遞訊息。
使用事務的訊息方式，防止了訊息的漏發或者不必要發的情況。
定時（延時）訊息
延時訊息用於指定訊息傳送到 MQ 伺服器端後，延時一段時間才被投遞到客戶端進行消費（例如 3 秒後才被消費），適用於解決一些訊息生產和消費有時間視窗要求的場景，或者通過訊息觸發延遲任務的場景，類似於延遲佇列。
順序訊息
順序訊息（FIFO 訊息）是 MQ 提供的一種嚴格按照順序進行釋出和消費的訊息型別。 順序訊息指訊息釋出和訊息消費都按順序進行。
- 順序釋出 ：對於指定的一個 Topic，客戶端將按照一定的先後順序傳送訊息。
- 順序消費 ：對於指定的一個 Topic，按照一定的先後順序接收訊息，即先發送的訊息一定會先被客戶端接收到。
分割槽順序
對於指定的一個 Topic，所有訊息根據 sharding key 進行區塊分割槽。 同一個分割槽內的訊息按照嚴格的 FIFO 順序進行釋出和消費。 Sharding key 是順序訊息中用來區分不同分割槽的關鍵欄位，和普通訊息的 Key 是完全不同的概念。
適用場景
效能要求高，以 sharding key 作為分割槽欄位，在同一個區塊中嚴格的按照 FIFO 原則進行訊息釋出和消費的場景。
示例
-
【例一】使用者註冊需要傳送發驗證碼，以使用者 ID 作為 sharding key， 那麼同一個使用者傳送的訊息都會按照先後順序來發布和訂閱。
-
【例二】電商的訂單建立，以訂單 ID 作為 sharding key，那麼同一個訂單相關的建立訂單訊息、訂單支付訊息、訂單退款訊息、訂單物流訊息都會按照先後順序來發布和訂閱。
阿里巴巴集團內部電商系統均使用分割槽順序訊息，既保證業務的順序，同時又能保證業務的高效能。
參考：
ofollow,noindex">如何解決MQ訊息消費順序問題
阿里雲官方文件