TCC概念

常見的分布式事務實現(xiàn)方案有以下幾種：兩階段提交（2PC）、三階段提交（3PC）、TCC（Try-Confirm-Cancel）、補償事務（Saga）、MQ事務消息等。 由于2PC資源鎖定時間較長，性能較差，難以擴展。TCC旨在解決這些問題，TCC是一種補償型事務模式，通過將每個事務操作分為三個階段：嘗試（Try）、確認（Confirm）和取消（Cancel），不僅優(yōu)化了事務的執(zhí)行流程，還提高了系統(tǒng)的整體效率和彈性。

TCC流程

TCC的核心思想在于將事務的每個操作拆分為三個明確的階段：嘗試（Try）、確認（Confirm）和取消（Cancel）。這三個階段各自承擔不同的職責，確保事務在分布式環(huán)境中能夠安全且一致地執(zhí)行。

• Try 階段

在這個階段，事務參與者將執(zhí)行所有必要的檢查，并預留必需的資源來保證事務可以順利完成。例如，在電商場景，當用戶嘗試購買商品時，系統(tǒng)將在Try階段檢查商品庫存，預留所需數(shù)量的商品。這個階段是整個TCC流程中的準備步驟，它不會做任何實際的業(yè)務處理，只是確保后續(xù)的Confirm階段可以無障礙地執(zhí)行。

• Confirm 階段

只有當所有參與者的Try階段成功完成后，才會進入Confirm階段。在這個階段，系統(tǒng)將正式執(zhí)行業(yè)務操作，使用在Try階段預留的資源。繼續(xù)舉例電商場景，如果用戶的支付成功，系統(tǒng)將在Confirm階段正式從庫存中扣除商品，完成交易。這一步驟確保了事務的最終一致性和數(shù)據(jù)的正確性。

• Cancel 階段

如果在Try階段或Confirm階段中的任何一個環(huán)節(jié)發(fā)生錯誤，或者某些業(yè)務條件未得到滿足，整個事務將進入Cancel階段。在這個階段，所有已經(jīng)預留的資源將被釋放，所有在Try階段所做的準備工作將被撤銷。例如，如果用戶決定取消購買，或者支付未成功，預留的商品庫存將被釋放，以便其他用戶購買。

電商場景介紹

舉一個常見的電商場景，用戶購買商品，點擊支付后。這時候交易系統(tǒng)需要做的操作是：

1. 更新訂單狀態(tài)為“已支付”
2. 扣減庫存
3. 增加用戶積分

圖片

電商系統(tǒng)一般采用微服務架構(gòu)，上述三個操作分別需要調(diào)用三個服務完成。流程如下：

1. 訂單服務，更新訂單狀態(tài)為“已支付”
2. 庫存服務，扣減庫存
3. 積分服務，增加用戶積分

如果這三個操作在一個服務中，就可以使用本地事務保證訂單、庫存、積分數(shù)據(jù)的一致性，但是現(xiàn)在需要調(diào)用三個服務，就無法保證數(shù)據(jù)的一致性了。 如果更新訂單狀態(tài)為“已支付”成功了，但是扣減庫存失敗了，其他用戶就可以繼續(xù)購買商品，可能會出現(xiàn)超賣問題，這時候就需要引入分布式事務，用來保證分布式系統(tǒng)中數(shù)據(jù)的一致性。

TCC落地電商場景

把上述電商場景引入TCC事務之后，就變成以下情況。

• Try階段實現(xiàn)

Try階段負責資源的預檢查和預留，分別調(diào)用三個服務凍結(jié)資源：

1. 訂單服務，更新訂單狀態(tài)為“支付中”
2. 庫存服務，凍結(jié)庫存（庫存表中，新增一個凍結(jié)庫存的字段）
3. 積分服務，預增加用戶積分（積分表，新增一個預增加積分的字段）

圖片

庫存表中，新增了一個凍結(jié)庫存的字段。在商品詳情頁面展示剩余庫存數(shù)量的時候，需要減去凍結(jié)庫存，防止超賣。

• Confirm 階段

當Try階段都執(zhí)行成功的時候，就進入Confirm階段，負責確認資源。流程如下：

1. 訂單服務，更新訂單狀態(tài)為“已支付”
2. 庫存服務，把凍結(jié)庫存扣減到剩余庫存上（update 剩余庫存=剩余庫存-凍結(jié)庫存，凍結(jié)庫存=0）
3. 積分服務，把預增加積分加到總積分上（udpate 總積分=總積分+預增加積分，預增加積分=0）

圖片

• Cancel階段

當Try階段任何一個操作失敗，就進入Cancel階段，負責回滾資源。流程如下：

1. 訂單服務，更新訂單狀態(tài)為“已取消”
2. 庫存服務，釋放凍結(jié)的庫存
3. 積分服務，釋放預增加積分

圖片

TCC問題

上述只是理想情況，在實踐的過程中會遇到以下三大問題，影響TCC事務的安全性。

1. Confirm/Cancel操作失敗問題
2. 空回滾問題
3. 懸掛問題

針對每個問題，我們思考一下相應的解決方案。

1. Confirm/Cancel操作失敗問題在執(zhí)行完Try階段之后，進入到Confirm或者Cancel階段，可能由于服務問題或者網(wǎng)絡問題，Confirm或者Cancel操作不一定能成功，通常采用的辦法是不斷重試，要求Confirm和Cancel接口要支持冪等。

2. 空回滾問題空回滾問題是指Try階段某個服務的Try操作沒有執(zhí)行成功或者沒有執(zhí)行，進入Cancel階段，就執(zhí)行Cancel操作回滾資源，導致數(shù)據(jù)錯亂。 常用的解決方案是Cancel操作前增加事務狀態(tài)檢查。

• 在 Try 操作開始時，設置事務狀態(tài)為 TRYING。
• 如果 Try 操作成功，更新狀態(tài)為 TRIED。
• 在 Cancel 操作執(zhí)行前，檢查狀態(tài)。如果狀態(tài)不是 TRIED，就不執(zhí)行 Cancel 操作。

3. 懸掛問題懸掛問題是指 Cancel 操作比 Try 操作先完成。通常出現(xiàn)的原因是由于網(wǎng)絡延遲，例如：由于調(diào)用Try操作耗時較長，出現(xiàn)網(wǎng)絡超時，導致Try操作調(diào)用失敗，就進入Cancel階段，執(zhí)行Cancel操作，而此時Try操作還在執(zhí)行，最后結(jié)果是Cancel操作執(zhí)行成功后，Try操作又執(zhí)行成功，出現(xiàn)“懸掛”問題。

解決方案有以下幾種：

1. 與空回滾解決方案類似，Cancel操作前增加事務狀態(tài)檢查。

• 在 Try 操作開始時，設置事務狀態(tài)為 TRYING。
• 如果 Try 操作成功，更新狀態(tài)為 TRIED。
• 在 Cancel 操作執(zhí)行前，檢查狀態(tài)。如果狀態(tài)不是 TRIED，就不執(zhí)行 Cancel 操作或者延遲執(zhí)行。

2. Try操作引入重試機制

如果調(diào)用Try操作超時，可以進行有限次重試，而不是立即執(zhí)行Cancel操作，可以減少因為網(wǎng)絡超時而導致的懸掛問題。這里要求Try接口也要支持冪等操作。

3. 增加同步機制

可以使用分布式鎖來控制Try和Cancel操作的執(zhí)行順序。

總結(jié)

TCC模型將事務分為Try、Confirm和Cancel三個階段，使得事務處理更加靈活和可控，保證了數(shù)據(jù)的一致性，減少了2PC資源鎖定時間過長的問題。但是也引入了一些新問題：

1. 代碼侵入嚴重。Try、Confirm和Cancel三個階段的事務操作都要耦合在業(yè)務邏輯中，耦合性較高。
2. 設計復雜，開發(fā)成本較高。對于TCC引入的冪等操作、空回滾問題、懸掛問題，都需要架構(gòu)設計的時候考慮相應的解決方案。

需要開發(fā)人員自行評估使用成本。