1、使用事務協調器，客戶端把多個資料請求傳送到事務協調器，由事務協調器傳送請求。
2、事務協調器傳送請求到不同的資料庫節點，並等待反饋
3、當所有節點反饋成功以後，事務協調器再向所有的資料庫節點傳送提交請求。
4、事務協調器收到提交完成的訊息後事務結束。
第一階段(提交請求階段)
協調者節點向所有參與者節點詢問是否可以執行提交操作，並等待各參與者節點的響應。
參與者節點執行詢問發起為止的所有事務操作，並將undo資訊和redo資訊寫入日誌。
各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回乙個"同意"訊息；如果參與者節點的事務操作實際執行失敗，則它返回乙個"中止"訊息。
第二階段(提交執行階段)
當協調者節點從所有參與者節點獲得的相應訊息都為"同意"時：
協調者節點向所有參與者節點發出"正式提交"的請求。
參與者節點正式完成操作，並釋放在整個事務期間內占用的資源。
參與者節點向協調者節點傳送"完了"訊息。
協調者節點受到所有參與者節點反饋的"完了"訊息後，完成事務。
優點： 盡量保證了資料的強一致，適合對資料強一致要求很高的關鍵領域。（不能100%保證）
缺點： 實現複雜，犧牲了可用性，對效能影響較大，不適合高併發高效能場景，如果分布式系統跨介面呼叫。
tcc 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊乙個與其對應的確認和補償（撤銷）操作。它分為三個階段：
try 階段主要是對業務系統做檢測及資源預留
confirm 階段主要是對業務系統做確認提交，try階段執行成功並開始執行 confirm階段時，預設 confirm階段是不會出錯的。即：只要try成功，confirm一定成功。
cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
優點： 跟2pc比起來，實現以及流程相對簡單了一些，但資料的一致性比2pc也要差一些
缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。tcc屬於應用層的一種補償方式，所以需要程式設計師在實現的時候多寫很多補償的**，在一些場景中，一些業務流程可能用tcc不太好定義及處理。
訊息生產方建乙個訊息表並記錄訊息傳送狀態。訊息表和業務資料要在乙個事務裡提交，他們要在乙個資料庫裡面。然後訊息經過mq傳送到訊息的消費方，如果訊息傳送失敗就會重試傳送。
訊息消費方需要處理這個訊息並完成自己的業務邏輯。如果處理失敗，那麼就會重試執行。如果是業務上面的失敗，可以給生產方傳送乙個業務補償訊息，通知生產方進行回滾等操作。
優點： 一種非常經典的實現，避免了分布式事務，實現了最終一致性。在 .net中 有現成的解決方案。
缺點： 訊息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...