1、簡述
分布式現在已經非常流利，好處很多，但是其中也是有很多的坑，比如事務。講到事務我們就聯想到了資料庫事務的幾個特性之一的一致性。如果是我們正常的單一系統的事務執行是沒什麼問題，但是如果是涉及多個分布式服務的事務就會存在一種問題，其中乙個或者多個服務事務提交失敗，這個時候就需要將所有相關服務的事務進行回滾，那麼這個時候該怎麼做呢？
如果讓我們去實現，那麼既然是事務不一致，那就把事務放到乙個事務組中，然後每個事務執行給乙個狀態，失敗了就全部回滾，成功就提交本地事。還有就是分別先提交了，如果其中乙個處理失敗就做補償操作，
2、解決方案
在分布式系統中，要實現分布式事務的方案。
一、兩階段提交（2pc）
兩階段提交（two-phase commit，2pc），通過引入協調者（coordinator）來協調參與者的行為，並最終決定這些參與者是否要真正執行事務。
執行過程
1.1 準備階段
協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。
1.2 提交階段
如果事務在每個參與者上都執行成功，事務協調者傳送通知讓參與者提交事務；否則，協調者傳送通知讓參與者回滾事務。
需要注意的是，在準備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知後，才進行提交或者回滾。
存在的問題
2.1 同步阻塞 所有事務參與者在等待其它參與者響應的時候都處於同步阻塞狀態，無法進行其它操作。
2.2 單點問題 協調者在 2pc 中起到非常大的作用，發生故障將會造成很大影響。特別是在階段二發生故障，所有參與者會一直等待狀態，無法完成其它操作。
2.3 資料不一致 在階段二，如果協調者只傳送了部分 commit 訊息，此時網路發生異常，那麼只有部分參與者接收到 commit 訊息，也就是說只有部分參與者提交了事務，使得系統資料不一致。
2.4 太過保守 任意乙個節點失敗就會導致整個事務失敗，沒有完善的容錯機制。
二、補償事務（tcc）
tcc 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊乙個與其對應的確認和補償（撤銷）操作。
優點： 跟2pc比起來，實現以及流程相對簡單了一些，但資料的一致性比2pc也要差一些
缺點： 缺點還是比較明顯的。tcc屬於應用層的一種補償方式，所以需要程式設計師在實現的時候多寫很多補償的**，在一些場景中，一些業務流程可能用tcc不太好定義及處理。
三、本地訊息表（非同步確保）
本地訊息表與業務資料表處於同乙個資料庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性，並且使用了訊息佇列來保證最終一致性。
在分布式事務操作的一方完成寫業務資料的操作之後向本地訊息表傳送乙個訊息，本地事務能保證這個訊息一定會被寫入本地訊息表中。
之後將本地訊息表中的訊息**到 kafka 等訊息佇列中，如果**成功則將訊息從本地訊息表中刪除，否則繼續重新**。
在分布式事務操作的另一方從訊息佇列中讀取乙個訊息，並執行訊息中的操作。
優點： 一種非常經典的實現，避免了分布式事務，實現了最終一致性。
缺點： 訊息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
四、mq 事務訊息
有一些第三方的mq是支援事務訊息的，比如rocketmq，他們支援事務訊息的方式也是類似於採用的二階段提交，但是市面上一些主流的mq都是不支援事務訊息的，比如 rabbitmq 和 kafka 都不支援。
以阿里的 rocketmq 中介軟體為例，其思路大致為：
第一階段prepared訊息，會拿到訊息的位址。 第二階段執行本地事務，第三階段通過第一階段拿到的位址去訪問訊息，並修改狀態。
也就是說在業務方法內要想訊息佇列提交兩次請求，一次傳送訊息和一次確認訊息。如果確認訊息傳送失敗了rocketmq會定期掃瞄訊息集群中的事務訊息，這時候發現了prepared訊息，它會向訊息傳送者確認，所以生產方需要實現乙個check介面，rocketmq會根據傳送端設定的策略來決定是回滾還是繼續傳送確認訊息。這樣就保證了訊息傳送與本地事務同時成功或同時失敗。
優點： 實現了最終一致性，不需要依賴本地資料庫事務。
缺點： 實現難度大，主流mq不支援，rocketmq事務訊息部分**也未開源。
以上解決方案是從網上找的幾個方案，參考博文：分布式事務的四種解決方案/
其實實際上還有很多別的方法處理，技術在更新人在進步，學無止境，方法也是如此。
----------------------------------------寫的不好，僅供參考
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...