還不懂分布式事務：帶你深入剖析TCC實現原理
TCC概念
常見的分布式事務實現方案有以下幾種：兩階段提交（2PC）、三階段提交（3PC）、TCC（Try-Confirm-Cancel）、補償事務（Saga）、MQ事務消息等。 由于2PC資源鎖定時間較長，性能較差，難以擴展。TCC旨在解決這些問題，TCC是一種補償型事務模式，通過將每個事務操作分為三個階段：嘗試（Try）、確認（Confirm）和取消（Cancel），不僅優化了事務的執行流程，還提高了系統的整體效率和彈性。
TCC流程
TCC的核心思想在于將事務的每個操作拆分為三個明確的階段：嘗試（Try）、確認（Confirm）和取消（Cancel）。這三個階段各自承擔不同的職責，確保事務在分布式環境中能夠安全且一致地執行。
- Try 階段
在這個階段，事務參與者將執行所有必要的檢查，并預留必需的資源來保證事務可以順利完成。例如，在電商場景，當用戶嘗試購買商品時，系統將在Try階段檢查商品庫存，預留所需數量的商品。這個階段是整個TCC流程中的準備步驟，它不會做任何實際的業務處理，只是確保后續的Confirm階段可以無障礙地執行。
- Confirm 階段
只有當所有參與者的Try階段成功完成后，才會進入Confirm階段。在這個階段，系統將正式執行業務操作，使用在Try階段預留的資源。繼續舉例電商場景，如果用戶的支付成功，系統將在Confirm階段正式從庫存中扣除商品，完成交易。這一步驟確保了事務的最終一致性和數據的正確性。
- Cancel 階段
如果在Try階段或Confirm階段中的任何一個環節發生錯誤，或者某些業務條件未得到滿足，整個事務將進入Cancel階段。在這個階段，所有已經預留的資源將被釋放，所有在Try階段所做的準備工作將被撤銷。例如，如果用戶決定取消購買，或者支付未成功，預留的商品庫存將被釋放，以便其他用戶購買。
電商場景介紹
舉一個常見的電商場景，用戶購買商品，點擊支付后。這時候交易系統需要做的操作是：
- 更新訂單狀態為“已支付”
- 扣減庫存
- 增加用戶積分
圖片
電商系統一般采用微服務架構，上述三個操作分別需要調用三個服務完成。流程如下：
- 訂單服務，更新訂單狀態為“已支付”
- 庫存服務，扣減庫存
- 積分服務，增加用戶積分
如果這三個操作在一個服務中，就可以使用本地事務保證訂單、庫存、積分數據的一致性，但是現在需要調用三個服務，就無法保證數據的一致性了。 如果更新訂單狀態為“已支付”成功了，但是扣減庫存失敗了，其他用戶就可以繼續購買商品，可能會出現超賣問題，這時候就需要引入分布式事務，用來保證分布式系統中數據的一致性。
TCC落地電商場景
把上述電商場景引入TCC事務之后，就變成以下情況。
- Try階段實現
Try階段負責資源的預檢查和預留，分別調用三個服務凍結資源：
- 訂單服務，更新訂單狀態為“支付中”
- 庫存服務，凍結庫存（庫存表中，新增一個凍結庫存的字段）
- 積分服務，預增加用戶積分（積分表，新增一個預增加積分的字段）
圖片
庫存表中，新增了一個凍結庫存的字段。在商品詳情頁面展示剩余庫存數量的時候，需要減去凍結庫存，防止超賣。
- Confirm 階段
當Try階段都執行成功的時候，就進入Confirm階段，負責確認資源。流程如下：
- 訂單服務，更新訂單狀態為“已支付”
- 庫存服務，把凍結庫存扣減到剩余庫存上（update 剩余庫存=剩余庫存-凍結庫存，凍結庫存=0）
- 積分服務，把預增加積分加到總積分上（udpate 總積分=總積分+預增加積分，預增加積分=0）
圖片
- Cancel階段
當Try階段任何一個操作失敗，就進入Cancel階段，負責回滾資源。流程如下：
- 訂單服務，更新訂單狀態為“已取消”
- 庫存服務，釋放凍結的庫存
- 積分服務，釋放預增加積分
圖片
TCC問題
上述只是理想情況，在實踐的過程中會遇到以下三大問題，影響TCC事務的安全性。
- Confirm/Cancel操作失敗問題
- 空回滾問題
- 懸掛問題
針對每個問題，我們思考一下相應的解決方案。
1. Confirm/Cancel操作失敗問題在執行完Try階段之后，進入到Confirm或者Cancel階段，可能由于服務問題或者網絡問題，Confirm或者Cancel操作不一定能成功，通常采用的辦法是不斷重試，要求Confirm和Cancel接口要支持冪等。
2. 空回滾問題空回滾問題是指Try階段某個服務的Try操作沒有執行成功或者沒有執行，進入Cancel階段，就執行Cancel操作回滾資源，導致數據錯亂。 常用的解決方案是Cancel操作前增加事務狀態檢查。
- 在 Try 操作開始時，設置事務狀態為 TRYING。
- 如果 Try 操作成功，更新狀態為 TRIED。
- 在 Cancel 操作執行前，檢查狀態。如果狀態不是 TRIED，就不執行 Cancel 操作。
3. 懸掛問題懸掛問題是指 Cancel 操作比 Try 操作先完成。通常出現的原因是由于網絡延遲，例如：由于調用Try操作耗時較長，出現網絡超時，導致Try操作調用失敗，就進入Cancel階段，執行Cancel操作，而此時Try操作還在執行，最后結果是Cancel操作執行成功后，Try操作又執行成功，出現“懸掛”問題。
解決方案有以下幾種：
- 與空回滾解決方案類似，Cancel操作前增加事務狀態檢查。
- 在 Try 操作開始時，設置事務狀態為 TRYING。
- 如果 Try 操作成功，更新狀態為 TRIED。
- 在 Cancel 操作執行前，檢查狀態。如果狀態不是 TRIED，就不執行 Cancel 操作或者延遲執行。
- Try操作引入重試機制
如果調用Try操作超時，可以進行有限次重試，而不是立即執行Cancel操作，可以減少因為網絡超時而導致的懸掛問題。這里要求Try接口也要支持冪等操作。
- 增加同步機制
可以使用分布式鎖來控制Try和Cancel操作的執行順序。
總結
TCC模型將事務分為Try、Confirm和Cancel三個階段，使得事務處理更加靈活和可控，保證了數據的一致性，減少了2PC資源鎖定時間過長的問題。但是也引入了一些新問題：
- 代碼侵入嚴重。Try、Confirm和Cancel三個階段的事務操作都要耦合在業務邏輯中，耦合性較高。
- 設計復雜，開發成本較高。對于TCC引入的冪等操作、空回滾問題、懸掛問題，都需要架構設計的時候考慮相應的解決方案。
需要開發人員自行評估使用成本。
