[[384133]]

本文轉(zhuǎn)載自微信公眾號「程序員jinjunzhu」，作者jinjunzhu 。轉(zhuǎn)載本文請聯(lián)系程序員jinjunzhu公眾號。

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

TCC回顧

TCC到底是什么呢?

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

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

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

try階段如果各個服務(wù)預(yù)留資源成功，協(xié)調(diào)節(jié)點就會對各服務(wù)下發(fā)commit命令，如下圖：

所有服務(wù)commit成功后，整個事務(wù)完成。

代碼實現(xiàn)

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

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

存在問題

上面TCC模式的代碼實現(xiàn)有問題嗎?

服務(wù)集群

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

所以如果真要用保持connection的方式來提交事務(wù)，協(xié)調(diào)節(jié)點就需要保證同一個xid對應(yīng)的try/commit/cancel請求到同一個機器上。

解決方案肯定有，改造注冊中心，或者協(xié)調(diào)節(jié)點自己維護服務(wù)列表。前者讓注冊中心耦合了業(yè)務(wù)代碼，后者相當(dāng)于廢棄了注冊中心。

空提交

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

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

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

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

冪等

如果協(xié)調(diào)節(jié)點設(shè)置了超時重試，發(fā)生了下圖的情況，訂單服務(wù)1執(zhí)行完try方法后發(fā)生故障，協(xié)調(diào)節(jié)點收不到成功回復(fù)必定會進行重試，這樣訂單服務(wù)就會重復(fù)執(zhí)行try方法。

為了規(guī)避這個問題，try/confirm/cancel方法都必須加入冪等邏輯，記錄全局事務(wù)xid對應(yīng)本地事務(wù)的執(zhí)行狀態(tài)。

空回滾

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

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

解決這個問題，try階段需要記錄xid對應(yīng)的分支事務(wù)執(zhí)行狀態(tài)，cancel階段根據(jù)這個記錄來進行判斷。

懸掛

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

解決這個問題的方法就是在cancel方法中記錄xid對應(yīng)的分支事務(wù)執(zhí)行狀態(tài)，try階段執(zhí)行的時候先判斷分支事務(wù)是否已經(jīng)回滾。

代碼侵入高

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

總結(jié)

TCC是分布式事務(wù)中非常經(jīng)典的模式，但即使借助框架實現(xiàn)，代碼實現(xiàn)也比較復(fù)雜。

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

對業(yè)務(wù)代碼侵入性很高。