首先來乙個具體的解決方案的示例
* 1、兩階段提交（2pc） 第一階段：事務協調器要求每個涉及到事務的資料庫預提交(precommit)此操作，並反映是否可以提交. 第二階段：事務協調器要求每個資料庫提交資料。 優點： 盡量保證了資料的強一致，適合對資料強一致要求很高的關鍵領域。（其實也不能100%保證強一致） 缺點： 實現複雜，犧牲了可用性，對效能影響較大，不適合高併發高效能場景，如果分布式系統跨介面呼叫，目前 .net 界還沒有實現方案。* 2、補償事務（tcc） 針對每個操作，都要註冊乙個與其對應的確認和補償（撤銷）。try、confirm、cancel 優點： 跟2pc比起來，實現以及流程相對簡單了一些，但資料的一致性比2pc也要差一些 缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。tcc屬於應用層的一種補償方式，所以需要程式設計師在實現的時候多寫很多補償的**，在一些場景中，一些業務流程可能用tcc不太好定義及處理。
* 3、本地訊息表（非同步確保） 核心思想是將分布式事務拆分成本地事務進行處理，訊息生產方，需要額外建乙個訊息表，並記錄訊息傳送狀態。訊息表和業務資料要在乙個事務裡提交，也就是說他們要在乙個資料庫裡面。然後訊息會經過mq傳送到訊息的消費方。如果訊息傳送失敗，會進行重試傳送。 優點： 一種非常經典的實現，避免了分布式事務，實現了最終一致性。在 .net中 有現成的解決方案。 缺點： 訊息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
* 4、mq事務訊息 rocketmq支援，rabbitmq 和 kafka 都不支援，一次傳送訊息和一次確認訊息，生產方需要實現乙個check介面（確認訊息或者回滾） 優點： 實現了最終一致性，不需要依賴本地資料庫事務。 缺點： 實現難度大，主流mq不支援，沒有.net客戶端，rocketmq事務訊息部分**也未開源。
* 5、sagas事務模型 長時間執行的事務，該模型其核心思想就是拆分分布式系統中的長事務為多個短事務，或者叫多個本地事務，然後由 sagas 工作流引擎負責協調，如果整個流程正常結束，那麼就算是業務成功完成，如果在這過程中實現失敗，那麼sagas工作流引擎就會以相反的順序呼叫補償操作，重新進行業務回滾。
MQ實現分布式事務
什麼是分布式事務 傳統的事務是基於單資料庫的本地事務，簡單的來說，分布式事務就是實現跨資料庫的事務支援 cap理論 cap理論表面在分布式系統中，最多只能滿足c，a，p中的兩個 既然最多只能選擇兩個，那選擇哪兩個比較合適呢？對於乙個分布式系統來說，可用性和分割槽容錯性是必須要滿足的。對於可用性，如果...
分布式事務六 常規MQ佇列
分布式事務二 分布式事務處理三 分布式事務四 基於可靠訊息的最終一致性 分布式事務五 基於可靠訊息的最終一致性 異常流程 分布式事務六 常規mq佇列 分布式事務七 冪等性設計 分布式事務八 可靠訊息最終一致性方案 分布式事務九 基於可靠訊息的最終一致性 分布式事務10 最大努力通知形勢 柔性事務解決...
MQ 分布式事務 微服務應用
以支付 電商下單為例子。乙個電商系統包含了好幾大類模組，就比如有使用者模組 商品模組 庫存模組 訂單模組 支付模組 物流模組，活動模組等，以下就先列舉幾個最基礎常見的模組 使用者模組 商品模組 庫存模組 訂單模組 支付模組 使用者流程如下 如果系統規模較小，資料表都在乙個資料庫例項上，專案服務端也都...