[[384133]]

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

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

TCC回顧

TCC到底是什么呢?

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

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

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

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

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

代碼實(shí)現(xiàn)

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

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

存在問題

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

服務(wù)集群

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

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

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

空提交

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

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

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

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

冪等

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

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

空回滾

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

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

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

懸掛

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

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

代碼侵入高

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

總結(jié)

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

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

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