TCC本質上也是一種二階段協議，不同在於TCC需要與具體業務耦合，下面首先看下TCC步驟:
所有事務參與方都需要實現try,confirm,cancle介面。
事務發起方向事務協調器發起事務請求，事務協調器呼叫所有事務參與者的try方法完成資源的預留，這時候並沒有真正執行業務，而是為後面具體要執行的業務預留資源，這裡完成了一階段。
如果事務協調器發現有參與者的try方法預留資源時候發現資源不夠，則呼叫參與方的cancle方法回滾預留的資源，需要注意cancle方法需要實現業務冪等，因為有可能呼叫失敗（比如網路原因參與者接受到了請求，但是由於網路原因事務協調器沒有接受到回執）會重試。
如果事務協調器發現所有參與者的try方法返回都OK，則事務協調器呼叫所有參與者的confirm方法，不做資源檢查，直接進行具體的業務操作。
如果協調器發現所有參與者的confirm方法都OK了，則分散式事務結束。
如果協調器發現有些參與者的confirm方法失敗了，或者由於網路原因沒有收到回執，則協調器會進行重試。這裡如果重試一定次數後還是失敗，會怎麼樣那？常見的是做事務補償。

對於TCC的解釋:
Try階段：嘗試執行,完成所有業務檢查（一致性）,預留必須業務資源（準隔離性）
Confirm階段：確認執行真正執行業務，不作任何業務檢查，只使用Try階段預留的業務資源，Confirm操作滿足冪等性。要求具備冪等設計，Confirm失敗後需要進行重試。
Cancel階段：取消執行，釋放Try階段預留的業務資源
Cancel操作滿足冪等性Cancel階段的異常和Confirm階段異常處理方案基本上一致。

螞蟻金服基於TCC實現了XTS（雲上叫DTS），目前在螞蟻金服雲上有對外輸出，這裡我們來結合其提供的一個例子來具體理解TCC的含義，以下引入螞蟻金服雲實例：

“首先我們假想這樣一種場景：轉賬服務，從銀行 A 某個賬戶轉 100 元錢到銀行 B 的某個賬戶，銀行 A 和銀行 B 可以認為是兩個單獨的系統，也就是兩套單獨的資料庫。

我們將賬戶系統簡化成只有賬戶和餘額 2 個欄位，並且為了適應 DTS 的兩階段設計要求，業務上又增加了一個凍結金額（凍結金額是指在一筆轉賬期間，在一階段的時候使用該欄位臨時儲存轉賬金額，該轉賬額度不能被使用，只有等這筆分散式事務全部提交成功時，才會真正的計入可用餘額）。按這樣的設計，使用者的可用餘額等於賬戶餘額減去凍結金額。這點是理解參與者設計的關鍵，也是 DTS 保證最終一致的業務約束。”

在try階段並沒有對銀行A和B資料庫中的餘額欄位做操作，而是對凍結金額做的操作，對應A銀行預留資源操作是對凍結金額加上100元，這時候A銀行賬號上可用錢為餘額欄位-凍結金額；對應B銀行的操作是對凍結金額上減去100，這時候B銀行賬號上可用的錢為餘額欄位-凍結金額。

如果事務協調器呼叫銀行A和銀行B的try方法有一個失敗了（比如銀行A的賬戶餘額不夠了），則呼叫cancle進行回滾操作（具體是對凍結金額做反向操作）。如果呼叫try方法都OK了，則進入confirm階段，confirm階段則不做資源檢查，直接做業務操作，對應銀行A要在賬戶餘額減去100，然後凍金額減去100；對應銀行B要對賬戶餘額欄位加上100，然後凍結金額加上100。

最關心的，如果confirm階段如果有一個參與者失敗了，該如何處理，其實上面操作都是xts-client做的，還有一個xts-server專門做事務補償的。