[[384133]]

本文轉載自微信公眾號「程序員jinjunzhu」，作者jinjunzhu 。轉載本文請聯系程序員jinjunzhu公眾號。

分布式事務的解決方案中，TCC是比較經典的模式，使用2階段提交的思想來實現分布式事務的最終一致。但最近我有點不喜歡TCC模式了。

TCC回顧

TCC到底是什么呢?

以經典的電商系統來說，客戶購買一件商品，系統需要3個服務來協作完成。訂單服務增加訂單，庫存服務扣減庫存，賬戶服務扣減金額。如下圖：

如果我們用上圖的方式，每個服務各自提交事務，很有可能會出現數據不一致的情況。因為3個服務使用不同數據庫，并不是一個原子操作，比如訂單服務提交成功而賬戶服務失敗了，這樣數據就不一致了。

TCC的思想是使用2階段提交，try階段首先嘗試各個服務預留資源，如果預留成功則進入commit階段提交事務，如果有一個服務預留失敗，那就進入cancel階段取消事務。這需要加入一個協調節點來對3個服務下發命令并且獲取每個服務的分支事務執行結果。try階段用下圖表示：

try階段如果各個服務預留資源成功，協調節點就會對各服務下發commit命令，如下圖：

所有服務commit成功后，整個事務完成。

代碼實現

協調節點需要給每個分布式事務提供一個全局事務id，叫做xid，用來跟每個服務的本地事務綁定。我們以賬戶服務為例，來看一下try/commit/cancel這3個階段的代碼：

這段代碼使用了jdbc來處理本地事務，try階段我們獲取了connection并且保存在connectionMap，key是xid，這樣在commit/cancel階段，從connectionMap中取出connection來commit/rollback。

存在問題

上面TCC模式的代碼實現有問題嗎?

服務集群

如下圖，如果訂單服務集群部署在3個機器上，try請求發送到訂單服務1，而commit請求發到訂單服務2上，訂單服務2的connectionMap怎么可能有xid=123的這個值呢?訂單服務本地事務不能提交了。

所以如果真要用保持connection的方式來提交事務，協調節點就需要保證同一個xid對應的try/commit/cancel請求到同一個機器上。

解決方案肯定有，改造注冊中心，或者協調節點自己維護服務列表。前者讓注冊中心耦合了業務代碼，后者相當于廢棄了注冊中心。

空提交

注冊中心和協調節點的改造都需要很大的工作量，有沒有別的方法呢?我們做一個改進，這里orm框架使用mybatis，代碼如下：

try階段要預留資源，這段代碼如果預留資源成功，其實已經提交分支事務了，commit階段只是一個空提交，沒有實際作用了。

還有一種方式就是try階段直接返回true，到commit階段真正提交事務。

但是這兩種方式都違背了TCC的思想。

冪等

如果協調節點設置了超時重試，發生了下圖的情況，訂單服務1執行完try方法后發生故障，協調節點收不到成功回復必定會進行重試，這樣訂單服務就會重復執行try方法。

為了規避這個問題，try/confirm/cancel方法都必須加入冪等邏輯，記錄全局事務xid對應本地事務的執行狀態。

空回滾

使用框架來實現TCC模式時，會有一種空回滾的情況。

如上圖，因為訂單服務1節點故障，try方法失敗，但是全局事務已經開啟，框架必須要把這個全局事務推向結束狀態，這樣就不得不調用訂單服務cancel方法進行回滾，結果訂單服務空跑了一次cancel方法。

解決這個問題，try階段需要記錄xid對應的分支事務執行狀態，cancel階段根據這個記錄來進行判斷。

懸掛

上面講了seata的使用過程中會發生空回滾，如果發生了空回滾，執行了cancel方法后全局事務結束了，但是因為網絡問題，訂單服務又收到了try請求，執行try方法后預留資源成功，這些資源卻不能釋放了。

解決這個問題的方法就是在cancel方法中記錄xid對應的分支事務執行狀態，try階段執行的時候先判斷分支事務是否已經回滾。

代碼侵入高

TCC的try/commit/cancel，對業務代碼都有侵入，如果再考慮冪等、空回滾、懸掛等，代碼侵入會更高。

總結

TCC是分布式事務中非常經典的模式，但即使借助框架實現，代碼實現也比較復雜。

實際使用時需要考慮服務集群、空提交、冪等、空回滾、懸掛等問題。

對業務代碼侵入性很高。