1、TCC簡介

TCC是一種比較成熟的分布式事務解決方案，可用于解決跨庫操作的數據一致性問題；

TCC是服務化的兩階段編程模型，其Try、Confirm、Cancel 3個方法均由業務編碼實現；

其中Try操作作為一階段，負責資源的檢查和預留，Confirm操作作為二階段提交操作，執行真正的業務，Cancel是預留資源的取消；

如下圖所示，業務實現TCC服務之后，該TCC服務將作為分布式事務的其中一個資源，參與到整個分布式事務中；事務管理器分2階段協調TCC服務，在第一階段調用所有TCC服務的Try方法，在第二階段執行所有TCC服務的Confirm或者Cancel方法；

2、用戶在實現TCC服務時，有以下注意事項

• 1、業務操作分兩階段完成：

如下圖所示，接入TCC前，業務操作只需要一步就能完成，但是在接入TCC之后，需要考慮如何將其分成2階段完成，把資源的檢查和預留放在一階段的Try操作中進行，把真正的業務操作的執行放在二階段的Confirm操作中進行；

TCC服務要保證第一階段Try操作成功之后，二階段Confirm操作一定能成功；

• 2、允許空回滾；

如下圖所示，事務協調器在調用TCC服務的一階段Try操作時，可能會出現因為丟包而導致的網絡超時，此時事務協調器會觸發二階段回滾，調用TCC服務的Cancel操作；

TCC服務在未收到Try請求的情況下收到Cancel請求，這種場景被稱為空回滾；TCC服務在實現時應當允許空回滾的執行；

• 3、防懸掛控制；

如下圖所示，事務協調器在調用TCC服務的一階段Try操作時，可能會出現因網絡擁堵而導致的超時，此時事務協調器會觸發二階段回滾，調用TCC服務的Cancel操作；在此之后，擁堵在網絡上的一階段Try數據包被TCC服務收到，出現了二階段Cancel請求比一階段Try請求先執行的情況；

用戶在實現TCC服務時，應當允許空回滾，但是要拒絕執行空回滾之后到來的一階段Try請求；

• 4、冪等控制：

無論是網絡數據包重傳，還是異常事務的補償執行，都會導致TCC服務的Try、Confirm或者Cancel操作被重復執行；用戶在實現TCC服務時，需要考慮冪等控制，即Try、Confirm、Cancel 執行一次和執行多次的業務結果是一樣的；

• 5、業務數據可見性控制；

TCC服務的一階段Try操作會做資源的預留，在二階段操作執行之前，如果其他事務需要讀取被預留的資源數據，那么處于中間狀態的業務數據該如何向用戶展示，需要業務在實現時考慮清楚；通常的設計原則是“寧可不展示、少展示，也不多展示、錯展示”；

• 6、業務數據并發訪問控制；

TCC服務的一階段Try操作預留資源之后，在二階段操作執行之前，預留的資源都不會被釋放；如果此時其他分布式事務修改這些業務資源，會出現分布式事務的并發問題；

用戶在實現TCC服務時，需要考慮業務數據的并發控制，盡量將邏輯鎖粒度降到最低，以最大限度的提高分布式事務的并發性；

3、總結

螞蟻金服使用TCC有10年歷史，在TCC應用方面積累了大量實踐經驗；除了上述TCC服務的設計注意事項外，我們在解決用戶高并發、高可用需求方面也提供了解決方案，我們對分布式事務做了極致的性能優化以支持雙11等大促的高并發需求，我們基于螞蟻LDC架構的高可用方案能使分布式事務服務達到99.99%的可用性；

螞蟻金服大部分業務系統均采用TCC的方式接入分布式事務，但設計TCC服務時要遵循大量設計規范，這無疑對用戶提了非常高的要求；為了簡化用戶接入分布式事務的門檻，螞蟻金服的分布式事務框架（SOFA-DTX）推出了FMT（Framework-managed transactions）模式和XA模式，這兩種模式均不需要用戶實現TCC服務，用戶只需要關注自身業務SQL便可；DTX的三種模式：TCC、FMT和XA相互之間是功能互補，相輔相成的，形成了螞蟻金服完善的分布式事務解決方案。

SOFA-DTX全面覆蓋金融場景，金融級容災保障、提供豐富的接入模式并且使用簡潔易于接入；目前已經應用在支付寶、網上銀行、螞蟻財富、芝麻信用、南京銀行等項目中。