訊息傳送一致性（可靠訊息的前提保障）
一、訊息中介軟體的應用場景
訊息中介軟體在分布式系統中的主要作用：非同步通訊、解耦、併發緩衝
如圖：通過引入訊息中介軟體來解耦應用間（服務間）的直接呼叫，同時也會起到非同步通訊和緩衝併發的作用
二、訊息傳送和投遞的不可靠性
三、訊息傳送一致性
訊息傳送一致性：是指產生訊息的業務動作與訊息傳送的一致。
（也就是說，如果業務操作成功，那麼由這個業務操作所產生的訊息一定要成功投遞出去，否則就丟訊息）
四、訊息傳送一致性如何保障？
1. 處理方式1
/** 支付訂單處理 **/
public void completeorder()
如果業務操作成功，執行訊息傳送前應用故障，訊息發不出去，導致訊息丟失（訂單系統與會計系統的資料不一致）
如果業務操作成功，應用正常，但訊息系統故障或網路故障，也會導致訊息發不出去（訂單系統與會計系統的資料不一致）
2. 處理方式2
/** 支付訂單處理 **/
public void completeorder()
這種情況下，更不可控，訊息發出去了，但業務可能會失敗（訂單系統與會計系統的資料不一致）
前面兩種方式，都不能保證業務資料的一致性。
五、jms標準中的xa協議方式是否可以保障傳送一致性？
jms協議標準的api中，有很多以xa開頭的介面，其實就是前面課程講到的支援xa協議（基於兩階段提交協議）的 全域性事務型介面。jms中的xa系列介面，可以提供分布式事務支援。 但引用了xa方式的分布式事務，又會帶來很多的侷限：
要求業務操作的資源必須支援xa協議（並不是所有資源都支援xa）
兩階段提交協議的成本
持久化成本等dtp模型的侷限性（全域性鎖定，成本高，效能低）
引入xa，違背了柔性事務的初衷
六、訊息傳送一致性：變通的做法
主動方應用先把訊息發給訊息中介軟體，訊息狀態標記為「待確認」；
訊息中介軟體收到訊息後，把訊息持久化到訊息儲存中，但並不向被動方應用投遞訊息；
訊息中介軟體返回訊息持久化結果（成功/失敗），主動方應用根據返回結果進行判斷如何進行業務操作處理：
失敗：放棄業務操作處理，結束（必要時向上層返回失敗結果）；
成功：執行業務操作處理；
業務操作完成後，把業務操作結果（成功/失敗）傳送給訊息中介軟體；
訊息中介軟體收到業務操作結果後，根據業務結果進行處理；
失敗：刪除訊息儲存中的訊息，結束；
成功：更新訊息儲存中的訊息狀態為「待傳送（可傳送）」，緊接著執行訊息投遞；
前面的正向流程都成功後，向被動方應用投遞訊息；
七、待解決問題
訊息傳送一致性方案的正向流程是可行的，但異常流程怎麼處理呢？ 訊息傳送到訊息中介軟體中能得到保障了，但訊息的準確消費（投遞）又如何保障呢？ 有沒有支援這種傳送一致性流程的現成訊息中介軟體？
分布式事務 解決方案之可靠訊息最終一致性理論
可靠訊息最終一致性 是指當事務發起方執行完成本地事務後發出一條訊息，事務參與方 訊息消費者 一定能夠接收訊息並處理成功，即強調的是只要訊息發給事務參與方最終事務要達到一致。該方案通常是利用訊息中介軟體完成，如下圖 事務發起方 訊息生產方 將訊息發給訊息中介軟體，事務參與方從訊息中介軟體接收訊息，事務...
基於訊息中介軟體的分布式事務
關於分布式事務的實現，網上有很多解說，當然這也是面試官的常備面試題。很多朋友在工作中很少接觸到分布式事務，認為這個玩意互動太多，沒必要。其實我也是這麼想的，想要完成乙個完整的分布式事務鏈路，通訊開銷實在太多。而現如今，微服務架構在行業內大行其道，恨不得所有模組都用上微服務來管理，而不知道自己已經慢慢...
基於RocketMQ的分布式事務
最近看到一篇分布式事務解決方案文章 柔性事務，要求最終一致性，允許中間狀態短期不一致。相對于強一致性事務 剛性事務 而言，它鎖定的資源範圍小，阻塞性弱，更為高效。柔性事務有多種實現方式，包括tcc saga 事務訊息 最大努力通知等，本文將重點介紹通過事務訊息實現柔性事務。以下為部分正文 針對搶購類...