讓您輕鬆理解分佈式事務解決方案之TCC

1.什麼是TCC

TCC是Try、Confirm、Cancel三個詞語的縮寫，TCC要求每個分支事務實現三個操作 ：預處理Try、確認Confirm、撤銷Cancel。Try操作做業務檢查及資源預留，Confirm做業務確認操作，Cancel實現一個與Try相反的操作既回滾操作。TM首先發起所有的分支事務的try操作，任何一個分支事務的try操作執行失敗，TM將會發起所有分支事務的Cancel操作，若try操作全部成功，TM將會發起所有分支事務的Confirm操作，其中Confirm/Cancel操作若執行失敗，TM會進行重試。

分支事務失敗的情況 ：

TCC分爲三個階段 ：

1. Try階段是做業務檢查（一致性）及資源預留（隔離），此階段僅是一個初步操作，它和後續的Confirm一起才能真正構成一個完整的業務邏輯。
2. Confirm階段是做確認提交，Try階段所有分支事務執行成功後開始執行Confirm。通常情況下，採用TCC則認爲Confirm階段是不會出錯的。即 ：只要Try成功，Confirm一定成功。若Confirm階段真的出錯了，需引入重試機制或人工處理。
3. Cancel階段是在業務執行錯誤需要回滾的狀態下執行分支事務的業務取消，預留資源釋放。通常情況下，採用TCC則認爲Cancel階段也是一定成功的。若Cancel階段真的出錯了，需引入重試機制或人工處理。
4. TM事務管理器
   TM事務管理器可以實現爲獨立的服務，也可以讓全局事務發起方充當TM的角色，TM獨立出來是爲了成爲公用組件，是爲了考慮結構和軟件複用。
   TM在發起全局事務時生成全局事務記錄，全局事務ID貫穿整個分佈式事務調用鏈條，用來記錄事務上下文，追蹤和記錄狀態，由於Confirm和Cancel失敗需進行重試，因此需要實現爲冪等性是指同一個操作無論請求多少次，其結果都相同。

2.TCC解決方案

目前業界對TCC的解決方案已經有很多了。

• tcc-transaction：https://github.com/changmingxie/tcc-transaction
• hmily：https://github.com/Dromara/hmily
• ByteTCC：https://github.com/liuyangming/ByteTCC
• EesyTransaction: https://github.com/QNJR-GROUP/EasyTransaction
• Seata TCC：https://github.com/seata/seata/tree/master/tcc