分布式事務指事務的操作位於不同的節點上，需要保證事務的 aicd 特性（事務特性見事務特性及隔離級別
）。例如在下單場景下，庫存和訂單如果不在同乙個節點上，就涉及分布式事務。
兩階段提交（two-phase commit, 2pc），通過引入協調者來協調參與者的行為，並最終決定這些參與者是否要真正執行事務。
兩階段提交的執行過程包括準備階段、提交階段兩個過程。
協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。
如果事務在每個參與者上都執行成功，事務協調者傳送通知讓參與者提交事務；否則，協調者傳送通知讓參與者回滾事務。需要注意的是，在準備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知後，才進行提交或者回滾。
tcc 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊乙個與其對應的確認和補償（撤銷）操作。它分為三個階段：
加入a要向b轉賬，其流程如下：
優點：跟2pc比起來，實現以及流程相對簡單了一些，但資料的一致性比2pc也要差一些。
缺點：tcc屬於應用層的一種補償方式，所以需要程式設計師在實現的時候多寫很多補償的**，在一些場景中，一些業務流程可能用tcc不太好定義及處理。
本地訊息表與業務資料表處於同乙個資料庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性，並且使用了訊息佇列來保證最終一致性。
優點： 一種非常經典的實現，避免了分布式事務，實現了最終一致性。
缺點： 訊息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
有一些第三方的mq是支援事務訊息的，比如rocketmq，他們支援事務訊息的方式也是類似於採用的二階段提交，但是市面上一些主流的mq都是不支援事務訊息的，比如 rabbitmq 和 kafka 都不支援。
以rocketmq中介軟體為例，其思路大致為：第一階段prepared訊息，會拿到訊息的位址。第二階段執行本地事務，第三階段通過第一階段拿到的位址去訪問訊息，並修改狀態。
也就是說在業務方法內要想訊息佇列提交兩次請求，一次傳送訊息和一次確認訊息。如果確認訊息傳送失敗了rocketmq會定期掃瞄訊息集群中的事務訊息，這時候發現了prepared訊息，它會向訊息傳送者確認，所以生產方需要實現乙個check介面，rocketmq會根據傳送端設定的策略來決定是回滾還是繼續傳送確認訊息。這樣就保證了訊息傳送與本地事務同時成功或同時失敗。
優點： 實現了最終一致性，不需要依賴本地資料庫事務。
缺點： 實現難度大，主流mq不支援，rocketmq事務訊息部分**也未開源。
分布式事務的四種解決方案
分布式事務指事務的操作位於不同的節點上，需要保證事務的 aicd 特性。例如在下單場景下，庫存和訂單如果不在同乙個節點上，就涉及分布式事務。在分布式系統中，要實現分布式事務，無外乎那幾種解決方案。兩階段提交 two phase commit，2pc 通過引入協調者 coordinator 來協調參與...
分布式事務的四種解決方案
分布式事務指事務的操作位於不同的節點上，需要保證事務的 aicd 特性。例如在下單場景下，庫存和訂單如果不在同乙個節點上，就涉及分布式事務。在分布式系統中，要實現分布式事務，無外乎那幾種解決方案。兩階段提交 two phase commit，2pc 通過引入協調者 coordinator 來協調參與...
分布式事務的四種解決方案
簡述 分布式事務指事務的操作位於不同的節點上，需要保證事務的 aicd 特性。例如在下單場景下，庫存和訂單如果不在同乙個節點上，就涉及分布式事務。解決方案 在分布式系統中，要實現分布式事務，無外乎那幾種解決方案。一 兩階段提交 2pc 兩階段提交 two phase commit，2pc 通過引入協...