TCC是 Try- Confirm-Cancel 這3個名詞的首字母簡稱，是一個2階段提交的變體思路。

Try：對資源的檢查和預(yù)留；

Confirm: 確認對預(yù)留資源的消耗，執(zhí)行業(yè)務(wù)操作；

Cancel：預(yù)留資源的釋放；

TCC的事務(wù)交互過程和AT類似，業(yè)務(wù)先發(fā)起全局事務(wù)，向TC申請全局XID，再把這個全局XID傳遞給各個微服務(wù)，各微服務(wù)在進行本地第一階段處理之前，都要向

TCC模式最重要的事情就是要把自己的業(yè)務(wù)模型都拆分為2個階段，能夠支持預(yù)留和確認兩個階段，并且需要自行編碼來實現(xiàn)try-confirm-cancel對應(yīng)的業(yè)務(wù)邏輯，深度侵入業(yè)務(wù)和代碼，當然帶來的好處也非常明顯，相比AT模式可以大大提高并發(fā)度。

常見的電商下單案例中，涉及商品庫存扣減、賬戶金額扣扣減、訂單創(chuàng)建 這3大業(yè)務(wù)，3個業(yè)務(wù)要支持TCC，首要的是把業(yè)務(wù)模型拆分為兩階段。

1、庫存扣減 2階段模型

? ? ?需要把庫存拆分為3部分： 實際庫存、可售庫存、凍結(jié)庫存

? ? ?其中 實際庫存 = 可售庫存+ 凍結(jié)庫存

? ? ?Try：增加凍結(jié)庫存、減少可售庫存、實際庫存保持不變

? ? ?Confirm： 什么都不做；

? ? ?Cancel：減少凍結(jié)庫存，增加可售庫存，實際庫存不變；

2、賬戶金額扣減的2階段模型和庫存扣減完全一致。

3、訂單創(chuàng)建 2階段模型

? ? ?訂單需要增加一個 創(chuàng)建中 狀態(tài)。

? ? ?Try : 訂單數(shù)據(jù)插入DB中，但是訂單狀態(tài)為 創(chuàng)建中；

? ? ?Confirm：訂單狀態(tài)變更為 正常狀態(tài)；

? ? ?Cancel：訂單狀態(tài)變更為? 無效狀態(tài)

TCC模式，第1階段庫存、賬戶、訂單這3者其實都是各自提交了本地事務(wù)，沒有全局鎖什么事，第2階段，無論是Confirm還是Cancel 也都是本地事務(wù)提交，也沒有全局事務(wù)什么事，基于這種模式對于各自業(yè)務(wù)的總體并發(fā)度幾乎沒有影響，不像AT模式還是有全局的行級鎖，整體式是串行的。