在分布式事務解決方案中有Seata AT模式，但是AT模式要求是關系型數據庫（因為undolog表需要和業務保持原子性），此時如果事務中存在非關系型數據庫（如Redis、ES等），那么AT模式就無法滿足要求了，如下圖所示：

圖片

此時我們就需要Seata TCC模式來幫助我們解決這種場景下的分布式事務問題。

1、認識Seata TCC模式

TCC(Try-Confirm-Cancel)模式是一種補償性事務模式的解決方案，因為補償的業務需要使用者自己寫，不像AT模式那樣的無侵入性的分布式事務處理方案，如下是TCC模式的執行流程圖：

圖片

TCC將一個完整的業務操作分為三個階段，如下圖整理所示：

圖片

Try階段：嘗試執行業務操作，預留必要的業務資源，并檢查數據的有效性。

Confirm階段：如果Try階段所有參與的操作都成功，則進入Confirm階段就會正式完成業務操作，提交事務，并釋放在Try階段預留的資源。

Cancel階段：如果Try階段有任何一個操作失敗，或者由于某種原因需要回滾事務，則觸發Cancel階段，撤銷所有已執行的Try操作，回滾到事務開始之前的狀態，并釋放預留的資源。

2、理解TCC模式

為了方便理解TCC模式，以A（賬戶總額1000元）向B（賬戶總額2000元）轉賬100元為例進行解析，那么TCC模式下的操作流程如下圖所示：

圖片

Try階段的工作：A賬戶先從總資金中扣除100元，但是這個100處于凍結狀態；B賬戶預增加100元，這個100處于不可用狀態。如下圖所示：

圖片

（a）如果A與B在Try階段都正常的執行，接下來就是執行Confirm階段的任務，A賬戶凍結100變成0元，這個100真正的轉給B賬戶；B賬戶的總額增加100元，預增加的金額變成0元，如下圖所示：

圖片

（b）如果A與B在Try階段未正常的執行，接下來A賬戶的凍結100變成0元，恢復A賬戶的資金的總額；B賬戶資金的總額不變化，預增加的金額變成0元，如下圖所示：

圖片

3、Seata TCC事務模型的三種異常

在TCC事務模型涉及到的三種異常（空回滾、冪等性、防懸掛）是不可避免的，下面我們來了解這三種異常發生的原因以及處理方案。

（1）空回滾

A調用C的時候，由于網絡抖動的原因導致C沒有請求成功，此時服務超時走兜底機制返回異常給A，如下圖所示：

圖片

當A發現B服務異常，TC就會通知A、B、C執行回滾操作，但是C由于Try階段都沒有執行就直接執行Cancel階段，最終就可能導致業務數據的不一致性。

空回滾處理方案：

Cancel執行的前提是一定要執行過Try階段，所以增加一個日志表來記錄是否執行Try階段，如果沒有執行Try階段，那么Cancel階段也不執行。

（2）冪等性

TCC中二階段的方法被多次的調用（二階段會有定時器不斷的重試），如下如所示：

圖片

冪等性處理方案：狀態機方式

在日志表中執行更新操作的時候（update log set status= 2 where status= 1）通過獲取影響行數來判斷是否執行成功，如果影響行數為0就不繼續處理；如果影響行數不為0就繼續Cancel的業務邏輯。

（3）防懸掛

由于網絡擁堵等原因導致A調用C的Try方法的請求發送成功，但是C與A之間自動斷開了連接，導致A認為C執行異常了，此時TC發送執行回滾操作命令，這就導致Cancel階段比Try先執行，如下圖所示：

圖片

當C服務做完Try階段的工作后，此時資源被預留出來了；但是Cancel已經執行完成了，表示那么整個事務就結束了，進而導致業務數據的不一致性。

防懸掛問題的處理方案：日志表

在Cancel執行完成之后要保證Try方法不能再執行了，此時在日志表中增加一條Cancel的記錄，等到Try執行的時候，其也要增加一條記錄，但是由于Cancel增加了日志記錄，此時Try就增加失敗，進而阻止Try繼續執行。

總結：

（1）TCC模式資源鎖定時間短：相較于傳統的兩階段提交(2PC)，TCC模式可以減少資源鎖定的時間，因為資源僅在Try階段被預留，并在Confirm或Cancel階段迅速釋放。

（2）TCC模式業務邏輯靈活：我們可以根據業務需求自定義每個階段的邏輯，使得TCC模式非常靈活。

（3）TCC模式保證強一致性：它可以確保事務要么都成功，要么都回滾。

（4）TCC模式實現復雜（需要為每個業務操作明確定義Try、Confirm和Cancel三個階段的邏輯）、增加了協調開銷、業務侵入性（業務邏輯與事務邏輯耦合）。