3.4.3　TCC事務(wù)

TCC是另一種常見的分布式事務(wù)機(jī)制，它是“Try-Confirm-Cancel”三個(gè)單詞的縮寫，是由數(shù)據(jù)庫專家Pat Helland在2007年撰寫的論文“Life beyond Distributed Transactions:An Apostate’s Opinion”[1]中提出。

前面介紹的可靠消息隊(duì)列雖然能保證最終結(jié)果的相對(duì)可靠性，過程也足夠簡(jiǎn)單（相對(duì)于TCC來說），但整個(gè)過程完全沒有任何隔離性可言，雖然在一些業(yè)務(wù)中隔離性是無關(guān)緊要的，但在有些業(yè)務(wù)中缺乏隔離性就會(huì)帶來許多麻煩。譬如在本章的場(chǎng)景事例中，缺乏隔離性會(huì)帶來的一個(gè)明顯問題便是“超售”：如兩個(gè)客戶在短時(shí)間內(nèi)都成功購買了同一件商品，而且他們各自購買的數(shù)量都不超過目前的庫存，但他們購買的數(shù)量之和卻超過了庫存。如果這件事情屬于剛性事務(wù)，且隔離級(jí)別足夠時(shí)是可以完全避免的，譬如，以上場(chǎng)景就需要“可重復(fù)讀”（Repeatable Read）的隔離級(jí)別，以保證后面提交的事務(wù)會(huì)因?yàn)闊o法獲得鎖而導(dǎo)致失敗，但用可靠消息隊(duì)列就無法保證這一點(diǎn)，這部分屬于數(shù)據(jù)庫本地事務(wù)方面的知識(shí)，可以參考前面的講解。如果業(yè)務(wù)需要隔離，那架構(gòu)師通常就應(yīng)該重點(diǎn)考慮TCC方案，該方案天生適用于需要強(qiáng)隔離性的分布式事務(wù)中。

在具體實(shí)現(xiàn)上，TCC較為煩瑣，它是一種業(yè)務(wù)侵入式較強(qiáng)的事務(wù)方案，要求業(yè)務(wù)處理過程必須拆分為“預(yù)留業(yè)務(wù)資源”和“確認(rèn)/釋放消費(fèi)資源”兩個(gè)子過程。如同TCC的名字所示，它分為以下三個(gè)階段。

·Try：嘗試執(zhí)行階段，完成所有業(yè)務(wù)可執(zhí)行性的檢查（保障一致性），并且預(yù)留好全部需要用到的業(yè)務(wù)資源（保障隔離性）。

·Confirm：確認(rèn)執(zhí)行階段，不進(jìn)行任何業(yè)務(wù)檢查，直接使用Try階段準(zhǔn)備的資源來完成業(yè)務(wù)處理。Confirm階段可能會(huì)重復(fù)執(zhí)行，因此本階段執(zhí)行的操作需要具備冪等性。

·Cancel：取消執(zhí)行階段，釋放Try階段預(yù)留的業(yè)務(wù)資源。Cancel階段可能會(huì)重復(fù)執(zhí)行，因此本階段執(zhí)行的操作也需要具備冪等性。

按照我們的場(chǎng)景事例，TCC的執(zhí)行過程應(yīng)該如圖3-8所示。

1）最終用戶向Fenix’s Bookstore發(fā)送交易請(qǐng)求：購買一本價(jià)值100元的《深入理解Java虛擬機(jī)》。

2）創(chuàng)建事務(wù)，生成事務(wù)ID，記錄在活動(dòng)日志中，進(jìn)入Try階段。

·用戶服務(wù)：檢查業(yè)務(wù)可行性，若可行，將該用戶的100元設(shè)置為“凍結(jié)”狀態(tài)，通知下一步進(jìn)入Confirm階段；若不可行，通知下一步進(jìn)入Cancel階段。

·倉庫服務(wù)：檢查業(yè)務(wù)可行性，若可行，將該倉庫的1本《深入理解Java虛擬機(jī)》設(shè)置為“凍結(jié)”狀態(tài)，通知下一步進(jìn)入Confirm階段；若不可行，通知下一步進(jìn)入Cancel階段。

·商家服務(wù)：檢查業(yè)務(wù)可行性，不需要凍結(jié)資源。

3）如果第2步所有業(yè)務(wù)均反饋業(yè)務(wù)可行，將活動(dòng)日志中的狀態(tài)記錄為Confirm，進(jìn)入Confirm階段。

圖3-8　TCC的執(zhí)行過程

·用戶服務(wù)：完成業(yè)務(wù)操作（扣減那被凍結(jié)的100元）。

·倉庫服務(wù)：完成業(yè)務(wù)操作（標(biāo)記那1本凍結(jié)的書為出庫狀態(tài)，扣減相應(yīng)庫存）。

·商家服務(wù)：完成業(yè)務(wù)操作（收款100元）。

4）第3步如果全部完成，事務(wù)正常結(jié)束，如果第3步中任何一方出現(xiàn)異常，不論是業(yè)務(wù)異常還是網(wǎng)絡(luò)異常，都將根據(jù)活動(dòng)日志中的記錄，重復(fù)執(zhí)行該服務(wù)的Confirm操作，即進(jìn)行最大努力交付。

5）如果第2步有任意一方反饋業(yè)務(wù)不可行，或任意一方超時(shí)，則將活動(dòng)日志的狀態(tài)記錄為Cancel，進(jìn)入Cancel階段。

·用戶服務(wù)：取消業(yè)務(wù)操作（釋放被凍結(jié)的100元）。

·倉庫服務(wù)：取消業(yè)務(wù)操作（釋放被凍結(jié)的1本書）。

·商家服務(wù)：取消業(yè)務(wù)操作。

6）第5步如果全部完成，事務(wù)宣告以失敗回滾結(jié)束，如果第5步中任何一方出現(xiàn)異常，不論是業(yè)務(wù)異常還是網(wǎng)絡(luò)異常，都將根據(jù)活動(dòng)日志中的記錄，重復(fù)執(zhí)行該服務(wù)的Cancel操作，即進(jìn)行最大努力交付。

由上述操作過程可見，TCC其實(shí)有點(diǎn)類似2PC的準(zhǔn)備階段和提交階段，但TCC是在用戶代碼層面，而不是在基礎(chǔ)設(shè)施層面，這為它的實(shí)現(xiàn)帶來了較高的靈活性，可以根據(jù)需要設(shè)計(jì)資源鎖定的粒度。TCC在業(yè)務(wù)執(zhí)行時(shí)只操作預(yù)留資源，幾乎不會(huì)涉及鎖和資源的爭(zhēng)用，具有很高的性能潛力。但是TCC也帶來了更高的開發(fā)成本和業(yè)務(wù)侵入性，即更高的開發(fā)成本和更換事務(wù)實(shí)現(xiàn)方案的替換成本，所以，通常我們并不會(huì)完全靠裸編碼來實(shí)現(xiàn)TCC，而是基于某些分布式事務(wù)中間件（譬如阿里開源的Seata）去完成，盡量減輕一些編碼工作量。

[1] 下載地址：https://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf。