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全面覆蓋金融場景，金融級容災保障、提供豐富的接入模式並且使用簡潔易於接入；目前已經應用在支付寶、網上銀行、螞蟻財富、芝麻信用、南京銀行等專案中。