在當(dāng)前如火如荼的互聯(lián)網(wǎng)浪潮下，如何應(yīng)對(duì)海量數(shù)據(jù)、高并發(fā)成為大家面臨的普遍難題。廣大IT公司從以往的集中式網(wǎng)站架構(gòu)，紛紛轉(zhuǎn)向分布式的網(wǎng)站架構(gòu)，隨之而來(lái)的就是進(jìn)行數(shù)據(jù)庫(kù)拆分和應(yīng)用拆分，如何在跨數(shù)據(jù)庫(kù)、跨應(yīng)用保證數(shù)據(jù)操作和業(yè)務(wù)操作的一致性、原子性，又成為需要解決的新的問(wèn)題。從分布式事務(wù)的需求來(lái)源來(lái)看：
1、跨數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)拆分(水平、垂直)帶來(lái)的分布式事務(wù)->保證跨庫(kù)操作的原子性
基于單個(gè)JVM

2、跨應(yīng)用

應(yīng)用拆分帶來(lái)的分布式事務(wù)->保證跨應(yīng)用業(yè)務(wù)操作的原子性
跨JVM

跨應(yīng)用的業(yè)務(wù)操作原子性要求，其實(shí)是比較常見(jiàn)的。比如在第三方支付場(chǎng)景中的組合支付，用戶(hù)在電商網(wǎng)站購(gòu)物后，要同時(shí)使用余額和紅包支付該筆訂單，而余額系統(tǒng)和紅包系統(tǒng)分別是不同的應(yīng)用系統(tǒng)，支付系統(tǒng)在調(diào)用這兩個(gè)系統(tǒng)進(jìn)行支付時(shí)，就需要保證余額扣減和紅包使用要么同時(shí)成功，要么同時(shí)失敗。

TCC事務(wù)的出現(xiàn)正是為了解決應(yīng)用拆分帶來(lái)的跨應(yīng)用業(yè)務(wù)操作原子性的問(wèn)題。當(dāng)然，由于常規(guī)的XA事務(wù)(2PC，2 Phase Commit, 兩階段提交)性能上不盡如人意，也有通過(guò)TCC事務(wù)來(lái)解決數(shù)據(jù)庫(kù)拆分的使用場(chǎng)景(如賬務(wù)拆分)，這個(gè)本文后續(xù)部分再詳述。

故從整個(gè)系統(tǒng)架構(gòu)的角度來(lái)看，分布式事務(wù)的不同方案是存在層次結(jié)構(gòu)的：

TCC的機(jī)制

明眼一看就知道，TCC應(yīng)該是三個(gè)英文單詞的首字母縮寫(xiě)而來(lái)。沒(méi)錯(cuò)，TCC分別對(duì)應(yīng)Try、Confirm和Cancel三種操作，這三種操作的業(yè)務(wù)含義如下：

Try：預(yù)留業(yè)務(wù)資源
Confirm：確認(rèn)執(zhí)行業(yè)務(wù)操作
Cancel：取消執(zhí)行業(yè)務(wù)操作

稍稍對(duì)照下關(guān)系型數(shù)據(jù)庫(kù)事務(wù)的三種操作：DML、Commit和Rollback，會(huì)發(fā)現(xiàn)和TCC有異曲同工之妙。在一個(gè)跨應(yīng)用的業(yè)務(wù)操作中，Try操作是先把多個(gè)應(yīng)用中的業(yè)務(wù)資源預(yù)留和鎖定住，為后續(xù)的確認(rèn)打下基礎(chǔ)，類(lèi)似的，DML操作要鎖定數(shù)據(jù)庫(kù)記錄行，持有數(shù)據(jù)庫(kù)資源；Confirm操作是在Try操作中涉及的所有應(yīng)用均成功之后進(jìn)行確認(rèn)，使用預(yù)留的業(yè)務(wù)資源，和Commit類(lèi)似；而Cancel則是當(dāng)Try操作中涉及的所有應(yīng)用沒(méi)有全部成功，需要將已成功的應(yīng)用進(jìn)行取消(即Rollback回滾)。其中Confirm和Cancel操作是一對(duì)反向業(yè)務(wù)操作。

簡(jiǎn)而言之，TCC是應(yīng)用層的2PC(2 Phase Commit, 兩階段提交)，如果你將應(yīng)用看做資源管理器的話(huà)。 詳細(xì)來(lái)說(shuō)，TCC每項(xiàng)操作需要做的事情如下：1、Try：嘗試執(zhí)行業(yè)務(wù)。

完成所有業(yè)務(wù)檢查(一致性)
預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性)

2、Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。

真正執(zhí)行業(yè)務(wù)
不做任何業(yè)務(wù)檢查
只使用Try階段預(yù)留的業(yè)務(wù)資源

3、Cancel：取消執(zhí)行業(yè)務(wù)

釋放Try階段預(yù)留的業(yè)務(wù)資源

用一張圖來(lái)說(shuō)明TCC的機(jī)制：

一個(gè)完整的TCC事務(wù)參與方包括三部分：

主業(yè)務(wù)服務(wù)：主業(yè)務(wù)服務(wù)為整個(gè)業(yè)務(wù)活動(dòng)的發(fā)起方，如前面提到的組合支付場(chǎng)景，支付系統(tǒng)即是主業(yè)務(wù)服務(wù)。
從業(yè)務(wù)服務(wù)：從業(yè)務(wù)服務(wù)負(fù)責(zé)提供TCC業(yè)務(wù)操作，是整個(gè)業(yè)務(wù)活動(dòng)的操作方。從業(yè)務(wù)服務(wù)必須實(shí)現(xiàn)Try、Confirm和Cancel三個(gè)接口，供主業(yè)務(wù)服務(wù)調(diào)用。由于Confirm和Cancel操作可能被重復(fù)調(diào)用，故要求Confirm和Cancel兩個(gè)接口必須是冪等的。前面的組合支付場(chǎng)景中的余額系統(tǒng)和紅包系統(tǒng)即為從業(yè)務(wù)服務(wù)。
業(yè)務(wù)活動(dòng)管理器：業(yè)務(wù)活動(dòng)管理器管理控制整個(gè)業(yè)務(wù)活動(dòng)，包括記錄維護(hù)TCC全局事務(wù)的事務(wù)狀態(tài)和每個(gè)從業(yè)務(wù)服務(wù)的子事務(wù)狀態(tài)，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作。

可見(jiàn)整個(gè)TCC事務(wù)對(duì)于主業(yè)務(wù)服務(wù)來(lái)說(shuō)是透明的，其中業(yè)務(wù)活動(dòng)管理器和從業(yè)務(wù)服務(wù)各自干了一部分工作。

TCC的優(yōu)點(diǎn)和限制

TCC事務(wù)的優(yōu)點(diǎn)如下：

解決了跨應(yīng)用業(yè)務(wù)操作的原子性問(wèn)題，在諸如組合支付、賬務(wù)拆分場(chǎng)景非常實(shí)用。
TCC實(shí)際上把數(shù)據(jù)庫(kù)層的二階段提交上提到了應(yīng)用層來(lái)實(shí)現(xiàn)，對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)是一階段提交，規(guī)避了數(shù)據(jù)庫(kù)層的2PC性能低下問(wèn)題。

TCC事務(wù)的缺點(diǎn)，主要就一個(gè)：

TCC的Try、Confirm和Cancel操作功能需業(yè)務(wù)提供，開(kāi)發(fā)成本高。

當(dāng)然，對(duì)TCC事務(wù)的這個(gè)缺點(diǎn)是否是缺點(diǎn)，是一個(gè)見(jiàn)仁見(jiàn)智的事情。

一個(gè)案例理解

TCC說(shuō)實(shí)話(huà)，TCC的理論有點(diǎn)讓人費(fèi)解。故接下來(lái)將以賬務(wù)拆分為例，對(duì)TCC事務(wù)的流程做一個(gè)描述，希望對(duì)理解TCC有所幫助。 賬務(wù)拆分的業(yè)務(wù)場(chǎng)景如下，分別位于三個(gè)不同分庫(kù)的帳戶(hù)A、B、C，A和B一起向C轉(zhuǎn)帳共80元：

1、Try：嘗試執(zhí)行業(yè)務(wù)。

完成所有業(yè)務(wù)檢查(一致性)：檢查A、B、C的帳戶(hù)狀態(tài)是否正常，帳戶(hù)A的余額是否不少于30元，帳戶(hù)B的余額是否不少于50元。
預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性)：帳戶(hù)A的凍結(jié)金額增加30元，帳戶(hù)B的凍結(jié)金額增加50元，這樣就保證不會(huì)出現(xiàn)其他并發(fā)進(jìn)程扣減了這兩個(gè)帳戶(hù)的余額而導(dǎo)致在后續(xù)的真正轉(zhuǎn)帳操作過(guò)程中，帳戶(hù)A和B的可用余額不夠的情況。

2、Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。

真正執(zhí)行業(yè)務(wù)：如果Try階段帳戶(hù)A、B、C狀態(tài)正常，且?guī)?hù)A、B余額夠用，則執(zhí)行帳戶(hù)A給賬戶(hù)C轉(zhuǎn)賬30元、帳戶(hù)B給賬戶(hù)C轉(zhuǎn)賬50元的轉(zhuǎn)帳操作。
不做任何業(yè)務(wù)檢查：這時(shí)已經(jīng)不需要做業(yè)務(wù)檢查，Try階段已經(jīng)完成了業(yè)務(wù)檢查。
只使用Try階段預(yù)留的業(yè)務(wù)資源：只需要使用Try階段帳戶(hù)A和帳戶(hù)B凍結(jié)的金額即可。

3、Cancel：取消執(zhí)行業(yè)務(wù)

釋放Try階段預(yù)留的業(yè)務(wù)資源：如果Try階段部分成功，比如帳戶(hù)A的余額夠用，且凍結(jié)相應(yīng)金額成功，帳戶(hù)B的余額不夠而凍結(jié)失敗，則需要對(duì)帳戶(hù)A做Cancel操作，將帳戶(hù)A被凍結(jié)的金額解凍掉。

小結(jié)：到底要不要使用TCC到底要不要使用TCC事務(wù)，取決于以下幾點(diǎn)：

是否真正有保證跨應(yīng)用業(yè)務(wù)操作的原子性需求。
研發(fā)上能否投入資源開(kāi)發(fā)相對(duì)應(yīng)的TCC接口。
當(dāng)然還有最后一點(diǎn)，能否搞定一個(gè)穩(wěn)定的、高可用的、擴(kuò)展性強(qiáng)的TCC事務(wù)管理器。

一個(gè)問(wèn)題，如果TCC事務(wù)在Try階段所有參與方(從業(yè)務(wù)服務(wù))成功了，但是Confirm階段部分參與方(從業(yè)務(wù)服務(wù))成功，如何處理？

TCC參考資料

《大規(guī)模SOA系統(tǒng)中的分布式事務(wù)處理》：螞蟻金服CTO程立早年的一篇關(guān)于分布式事務(wù)的PPT，里面有關(guān)于大規(guī)模SOA系統(tǒng)中包括TCC在內(nèi)的各種分布式事務(wù)處理方案，是支付寶在分布式事務(wù)實(shí)踐的經(jīng)驗(yàn)精華。

《Atomic Distributed Transactions: a RESTful Design》：ATOMIKOS公司的Guy Pardon和另一位作者一同寫(xiě)的一篇關(guān)于TCC事務(wù)設(shè)計(jì)方案的論文，對(duì)TCC的實(shí)現(xiàn)細(xì)節(jié)描述較為清楚。

TCC的開(kāi)源產(chǎn)品

可以參考一下開(kāi)源的TCC實(shí)現(xiàn)ByteTCC。

ByteTCC是一個(gè)基于TCC（Try/Confirm/Cancel）事務(wù)補(bǔ)償機(jī)制的分布式事務(wù)管理器，兼容JTA，因此可以很好的與EJB、Spring等容器（本文檔下文說(shuō)明中將以Spring容器為例）進(jìn)行集成，支持Spring容器的聲明式事務(wù)。

用戶(hù)指南：https://github.com/liuyangming/ByteTCC/wiki

TCC是一個(gè)理念，其由Atomikos公司的創(chuàng)始人提出，如果想了解其具體內(nèi)容直接到其官網(wǎng)下載個(gè)白皮書(shū)看下就好了，任何時(shí)候都是看官方文檔才能更準(zhǔn)確的獲知答案。不過(guò)TCC只是分布式事務(wù)中的一個(gè)選項(xiàng)，且并非最優(yōu)選項(xiàng)，這里有篇文章介紹

https://github.com/QNJR-GROUP/EasyTransaction

https://github.com/prontera/spring-cloud-rest-tcc

總結(jié)

以上是生活随笔為你收集整理的分布式事务之：TCC (Try-Confirm-Cancel) 模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。