實作步驟
步驟1 - 可靠的消息生産記錄消息發送
隐患
- 可能消息發送失敗：
-
基于RabbitMQ消息隊列的分布式事務解決方案(下)4 總結 - 為確定資料一定成功發送到MQ。在同一事務中，增加一個記錄表的操作, 記錄
每一條發往MQ的資料以及它的發送狀态
- 于是在訂單系統中增加一個本地資訊表
不再通過HTTP請求直接調用運單系統接口，而是使用MQ：
生成訂單時，也儲存本地資訊表
步驟2-可靠消息生産(修改消息發送狀态)
- 利用RabbitMQ的事務釋出确認機制(confirm)：開啟後，MQ準确受理消息會傳回回執
-
基于RabbitMQ消息隊列的分布式事務解決方案(下)4 總結
然後就能知道如何更新本地資訊表
確定在SpringBoot項目中開啟Confirm機制
代碼實作
-
若出現回執沒收到、消息狀态修改失敗等特殊情況
兜底方案：定時檢查消息表，逾時沒發送成功，再次重發。
步驟3 - 可靠消息處理(正常處理)
- 運單系統收到消息資料後，突然當機或通路運單DB時，DB突然當機，消息資料不就丢了？
-
基于RabbitMQ消息隊列的分布式事務解決方案(下)4 總結 - 于是還需要如下處理：
➢ 幂等性
防止重複消息資料的處理，一次使用者操作，隻對應一次資料處理
➢ 開啟
手動ACK模式
由消費者控制消息的重發/清除/丢棄
步驟4 - 可靠消息處理(消息重發)
消費者處理失敗，需要MQ重發給消費者。出現異常一般會重試幾次，由消費者自身記錄重試次數，并進行次數控制。
步驟五 - 可靠消息處理(消息丢棄)
消費者處理失敗，直接丢棄或者轉移到死信隊列(DLQ)。
重試次數過多、消息内容格式錯誤等情況，通過線上預警機制通知運維
4 總結
MQ實作分布式事務分析
優點
- 通用性強
- 拓展性強
- 方案成熟
缺點
- 基于消息中間件，隻适合異步場景
- 消息處理會有延遲，需要業務上能夠容忍
盡量避免分布式事務，盡量将非核心事務做成異步。
參考
https://tech.meituan.com/2018/07/26/peisong-sys-arch-evolution.html