分散式事務的實現方式
TCC
參與角色
業務活動管理器（協調者）、業務服務
TCC解釋
Try階段：嘗試執行,完成所有業務檢查（一致性）,預留必須業務資源（準隔離性）
Confirm階段：確認執行真正執行業務，不作任何業務檢查，只使用Try階段預留的業務資源，Confirm操作滿足冪等性。要求具備冪等設計，Confirm失敗後需要進行重試。
Cancel階段：取消執行，釋放Try階段預留的業務資源 Cancel操作滿足冪等性Cancel階段的異常和Confirm階段異常處理方案基本上一致。
實現
PS：所有業務需要實現TCC介面；通過補償可以實現最終一致性。
例項
舉個簡單的例子如果你用100元買了一瓶水， Try階段:你需要向你的錢包檢查是否夠100元並鎖住這100元，水也是一樣的。如果有一個失敗，則進行cancel(釋放這100元和這一瓶水)，如果cancel失敗不論什麼失敗都進行重試cancel，所以需要保持冪等。如果都成功，則進行confirm,確認這100元扣，和這一瓶水被賣，如果confirm失敗無論什麼失敗則重試(會依靠活動日誌進行重試)
資料庫分散式事務中的 XA Transactions
角色
事務管理器（協調者）、業務服務
實現
第一階段：事務管理器要求每個涉及到事務的資料庫預提交(precommit)此操作，並反映是否可以提交.
第二階段：事務協調器要求每個資料庫提交資料，或者回滾資料。
PS： XA協議基於2pc協議實現。
MQ
角色
訊息中介軟體、業務服務
實現
第一階段Prepared訊息，會拿到訊息的地址。
執行本地事務。
第二階段確認訊息傳送，如果確認訊息失敗，在RocketMq Broker中提供了定時掃描沒有更新狀態的訊息，如果有訊息沒有得到確認，會向訊息傳送者傳送訊息，來判斷是否提交
第三階段中介軟體傳送訊息給其它業務服務。如果 傳送超時，則需要一直髮送。
第四階段其它業務服務處理完成之後，需要通過中介軟體反饋給發起者。如果處理失敗，則需要人工處理（由人工決定是否回滾或者繼續）。
SAGA
角色
協調器、業務服務
實現
由Saga事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次呼叫補償操作