基于RabbitMQ消息隊列的分布式事務解決方案 - MQ分布式消息中間件實戰

1 極速了解MQ

介紹Rabbitmg用于解決分布式事務必須掌握的5個核心概念

一款分布式消息中間件，基于erlang語言開發， 具備語言級别的高并發處理能力。和Spring架構是同一家公司。

支援持久化、高可用

核心5個概念:

1. Queue: 真正存儲資料的地方
2. Exchange: 接收請求，轉存資料
3. Bind: 收到請求後存儲到哪裡
4. 消息生産者:發送資料的應用
5. 消息消費者: 取出資料處理的應用

   

2、分布式事務問題

分布式事務是一個業務問題，不能脫離具體的場景。

2.1 分布式事務的幾種解決方案

● 基于資料庫XA/ JTA協定的方式

需要資料庫廠商支援; JAVA元件有atomikos等

● 異步校對資料的方式

支付寶、微信支付主動查詢支付狀态、對賬單的形式;

● 基于可靠消息(MQ)的解決方案

異步場景;通用性較強;拓展性較高

● TCC程式設計式解決方案

嚴選、阿裡、螞蟻金服自己封裝的DTX

本文目标:針對所有人群，學會基于可靠消息來解決分布式事務問題。

分布式事務的解決方案，業務針對性很強，重要的是思路，而不是照搬

• 美團點評系統架構

  

2.2 多系統間的分布式事務問題

• 使用者下單生成訂單

  

• 需要傳遞訂單資料,由此産生兩個事務一緻性問題

  

錯誤的案例

當接口調用失敗時，訂單系統事務復原,提示使用者操作失敗

誤以為這樣的接口調用寫法，就不會有分布式事務問題

接口調用成功或者失敗，都會産生分布式事務問題:

1. 接口調用成功，訂單系統資料庫事務送出失敗，運單系統沒有復原，産生資料
2. 接口調用逾時，訂單系統資料庫事務復原，運單系統接口繼續執行，産生資料

上述兩種情況，都會導緻資料不一緻的問題

3、實作分布式事務 - 五步法

通過MQ解決分布式事務的5個步驟, 以及分布式事務進行中要注意的地方

• 之前都是訂單系統發送HTTP請求運單系統的接口,出問題了!

  

• 是以我們考慮發消息給MQ, 異步暫存!

  

3.1 整體設計思路

外賣下訂單後,可以慢慢等待運單中心資料生成,并非強制要求同時性

1. 可靠生産:保證消息一定要發送到Rabitmq服務
2. 可靠消費:保證消息取出來一定正确消費掉

最終使多方資料達到一緻。

3.2 步驟1 - 可靠的消息生産記錄消息發送

• 存在隐患 - 可能消息發送失敗呀!

  

為了確定資料一定成功發送到MQ。

在同一事務中，增加一個記錄表的操作, 記錄

每一條發往MQ的資料以及它的發送狀态

于是我們在訂單系統中增加一個本地資訊表

于是在代碼實踐中,不再通過HTTP接口調用運單系統接口,而是使用MQ

生成訂單時,也儲存本地資訊表

3.3 步驟2 - 可靠消息生産(修改消息發送狀态)

• 利用RabbitMQ事務釋出确認機制(confirm)

  開啟後，MQ準确受理消息會傳回回執

• 然後就能知道如何更新本地資訊表了

  

-確定在SB中開啟Confirm機制

• 如果出現回執沒收到、消息狀态修改失敗等特殊情況

  兜底方案:定時檢查消息表，逾時沒發送成功，再次重發

3.4 步驟3 - 可靠消息處理(正常處理)

• 運單系統收到消息資料後,突然當機,或者通路運單DB時,DB突然當機,消息資料不就丢了嗎!!!

  

于是需要以下特性:

幂等性

防止重複消息資料的處理，一次使用者操作，隻對應一次資料處理

開啟

手動ACK模式

由消費者控制消息的重發/清除/丢棄

3.5 步驟4 - 可靠消息處理(消息重發)

消費者處理失敗，需要MQ再次重發給消費者。

出現異常一般會重試幾次，由消費者自身記錄重試次數，并進行次數控制(不會永遠重試!)

3.6 步驟五 - 可靠消息處理(消息丢棄)

消費者處理失敗，直接丢棄或者轉移到死信隊列(DLQ)

重試次數過多、消息内容格式錯誤等情況，通過線上預警機制通知運維人員

4 總結及擴充

4.1 MQ方案的優點和缺點

口優點

1. 通用性強
2. 拓展性強
3. 方案成熟

口缺點

1. 基于消息中間件，隻适合異步場景
2. 消息處理會有延遲，需要業務上能夠容忍

盡量避免分布式事務;

盡量将非核心事務做成異步;

4.2 拓展

分布式事務解決方案的理論依據

CAP理論

BASE理論

2PC協定

3PC協定

Paxos算法.

Raft一緻性協定

參考

美團配送系統架構演進實踐