我有點不喜歡分布式中的TCC模式了

作者： jinjunzhu 2021-03-01 08:35:23

開發(fā)

前端

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

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

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

TCC回顧

TCC到底是什么呢?

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

 

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

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

 

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

 

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

代碼實現(xiàn)

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

 

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

存在問題

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

服務集群

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

 

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

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

空提交

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

 

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

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

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

冪等

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

 

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

空回滾

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

 

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

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

懸掛

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

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

代碼侵入高

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

總結

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

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

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

分享文章：我有點不喜歡分布式中的TCC模式了
URL網(wǎng)址：http://m.5511xx.com/article/dhgodpj.html