分佈式事務的實現方式

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事務協調器協調，若是正常結束那就正常完成，若是某個步驟失敗，則根據相反順序一次調用補償操做