RocketMQ
消息隊列 RocketMQ 版是阿里雲基於 Apache RocketMQ 構建的低延遲、高併發、高可用、高可靠的分佈式消息中間件。消息隊列 RocketMQ 版既可爲分佈式應用系統提供異步解耦和削峯填谷的能 力，同時也具備互聯網應用所需的海量消息堆積、高吞吐、可靠重試等特性。
建議統一消息格式
統一消息格式，message由兩部分組成
-
id：由生產者生成，每次不重複，代表一條消息。消費者可用於做冪等。 -
timestamp：消息的創建時間，消費方可根據業務需求，拒絕某個時間點前的消息。 -
traceId: 鏈路id，用於追溯業務鏈路。 -
payload：業務數據。
異步解耦
最常見的一個場景是用戶註冊後，需要發送註冊郵件和短信通知，以告知用戶註冊成功。
傳統實現（串行）：
以上三個任務全部完成後，才返回註冊結果到客戶端，用戶才能使用賬號登錄。
假設每個任務耗時分別爲 50 ms，則用戶需要在註冊頁面等待總共需要 150 ms 才能登錄。
異步解耦實現：
對於用戶來說，註冊功能實際只需要註冊系統存儲用戶的賬戶信息後，該用戶便可以登錄，後續的註冊短信和郵件不是即時需要關注的步驟。
對於註冊系統而言，發送註冊成功的短信和郵件通知並不一定要綁定在一起同步完成，所以實際當數據寫入註冊系統後，註冊系統就可以把其他的操作放入對應的消息隊列 RocketMQ 版中然後馬上返回用戶結果，由消息隊列 RocketMQ 版異步地進行這些操作。
分佈式事務的數據一致性方案
1、本地消息表
本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分佈式事務拆分成本地事務進行處理，這種思路是來源於ebay。我們可以從下面的流程圖中看出其中的一些細節：
基本思路就是：
消息生產方，需要額外建一個消息表，並記錄消息發送狀態。消息表和業務數據要在一個事務裏提交，也就是說他們要在一個數據庫裏面。然後消息會經過MQ發送到消息的消費方。如果消息發送失敗，會進行重試發送。
消息消費方，需要處理這個消息，並完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那麼就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償消息，通知生產方進行回滾等操作。
2、事務消息處理
主要用來保證本地事務和消息發送，要麼同時成功要麼同時失敗。
事務消息交互流程如下：
- 生產者將消息發送至MQ服務端，MQ服務端會將消息持久化至文件中；
- MQ服務端向發送方返回 Ack 確認消息已經發送成功，此時發送方開始執行本地事務邏輯；
- 發送方根據本地事務執行結果向服務端提交本地事務結果（Commit 或是 Rollback），服務端收到 Commit 狀態則將事務消息標記爲可投遞，訂閱方開始消費該消息；
消息的順序收發
順序消息分爲兩種情況：
全局順序：對於指定的一個 Topic，所有消息將按照嚴格的先入先出（FIFO）的順序，進行順序發佈和順序消費；
分區順序：對於指定的一個 Topic，所有消息根據 Sharding Key 進行區塊分區，同一個分區內的消息將按照嚴格的 FIFO 的順序，進行順發布和順序消費，可以保證一個消息被一個進程消費。
削峯填谷
流量削峯也是消息隊列 MQ 的常用場景，一般在秒殺或團隊搶購活動中使用廣泛。
在秒殺或團隊搶購活動中，由於用戶請求量較大，導致流量暴增，秒殺的應用在處理如此大量的訪問流量後，下游的通知系統無法承載海量的調用量，甚至會導致系統崩潰等問題而發生漏通知的情況。爲解決這些問題，可在應用和下游通知系統之間加入MQ 。
大規模機器的緩存同步
雙十一大促時，各個分會場會有玲琅滿目的商品，每件商品的價格都會實時變化。使用緩存技術也無法滿足對商品價格的訪問需求，緩存服務器網卡滿載。訪問較多次商品價格查詢影響會場頁面的打開速度。
此時需要提供一種廣播機制，一條消息本來只可以被集羣的一臺機器消費，如果使用消息隊列的廣播消費模式，那麼這條消息會被所有節點消費一次，相當於把價格信息同步到需要的每臺機器上，取代緩存的作用。