正文

我們先套一個(gè)業(yè)務(wù)場(chǎng)景進(jìn)去，如下圖所示

在成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)過(guò)程中，需要針對(duì)客戶(hù)的行業(yè)特點(diǎn)、產(chǎn)品特性、目標(biāo)受眾和市場(chǎng)情況進(jìn)行定位分析，以確定網(wǎng)站的風(fēng)格、色彩、版式、交互等方面的設(shè)計(jì)方向。創(chuàng)新互聯(lián)建站還需要根據(jù)客戶(hù)的需求進(jìn)行功能模塊的開(kāi)發(fā)和設(shè)計(jì)，包括內(nèi)容管理、前臺(tái)展示、用戶(hù)權(quán)限管理、數(shù)據(jù)統(tǒng)計(jì)和安全保護(hù)等功能。

那頁(yè)面點(diǎn)了支付按鈕，調(diào)用支付服務(wù)，那我們后臺(tái)要實(shí)現(xiàn)下面三個(gè)步驟
[1] 訂單服務(wù)-修改訂單狀態(tài)
[2] 賬戶(hù)服務(wù)-扣減金錢(qián)
[3] 庫(kù)存服務(wù)-扣減庫(kù)存
達(dá)到事務(wù)的效果，要么一起成功，要么一起失??！就要采取TCC分布式事務(wù)方案！

概念

TCC的全稱(chēng)是（Try-Confirm-Cancel）。如下圖所示

ps:TCC又可以被稱(chēng)為兩階段補(bǔ)償事務(wù)，第一階段try只是預(yù)留資源，第二階段要明確的告訴服務(wù)提供者，這個(gè)資源你到底要不要，對(duì)應(yīng)第二階段的confirm/cancel，用來(lái)清除第一階段的影響，所以叫補(bǔ)償型事務(wù)。

再打個(gè)比方，說(shuō)TCC太高大上是吧，講RM中的prepare、commit、rollback接口，總知道吧?？梢灶?lèi)比的這么理解

那差別在哪呢?
rollback、commit、prepare，站在開(kāi)發(fā)者層面是感知不到的，數(shù)據(jù)庫(kù)幫你做了資源的操作!
而try、confirm、cancel，站在開(kāi)發(fā)者層面是能感知到的，這三個(gè)方法的業(yè)務(wù)邏輯，即對(duì)資源的操作，開(kāi)發(fā)者是要自己去實(shí)現(xiàn)的！
好，下面套入我們的場(chǎng)景，怎么做呢。比如，你的訂單服務(wù)中本來(lái)只有一個(gè)接口

//修改代碼狀態(tài)
orderClient.updateStatus()；

都要拆為三個(gè)接口，即

orderClient.tryUpateStatus()；
orderClient.confirmUpateStatus()；
orderClient.cancelUpateStatus()；

注意了：面試官如果問(wèn)你，TCC有什么缺點(diǎn)？這就是很?chē)?yán)重的缺點(diǎn)，對(duì)代碼***性大！每套業(yè)務(wù)邏輯、都要按try(請(qǐng)求資源)、confirm(操作資源)、cancel(取消資源)，拆分為三個(gè)接口！

具體每個(gè)階段，每個(gè)服務(wù)業(yè)務(wù)邏輯是什么樣的呢?
假設(shè)，庫(kù)存數(shù)量本來(lái)是50，那么可銷(xiāo)售庫(kù)存也是50。賬戶(hù)余額為50,可用余額也為50。用戶(hù)下單，買(mǎi)了1個(gè)單價(jià)為1元的商品。流程如下:
Try階段
訂單服務(wù):修改訂單的狀態(tài)為支付中
賬戶(hù)服務(wù):賬戶(hù)余額不變，可用余額減1，然后將1這個(gè)數(shù)字凍結(jié)在一個(gè)單獨(dú)的字段里
庫(kù)存服務(wù):庫(kù)存數(shù)量不變，可銷(xiāo)售庫(kù)存減1，然后將1這個(gè)數(shù)字凍結(jié)在一個(gè)單獨(dú)的字段里
confirm階段
訂單服務(wù):修改訂單的狀態(tài)為支付完成
賬戶(hù)服務(wù):賬戶(hù)余額變?yōu)?當(dāng)前值減凍結(jié)字段的值)，可用余額不變(Try階段減過(guò)了),凍結(jié)字段清0。
庫(kù)存服務(wù):庫(kù)存變?yōu)?當(dāng)前值減凍結(jié)字段的值)，可銷(xiāo)售庫(kù)存不變(Try階段減過(guò)了)，凍結(jié)字段清0。
cancel階段
訂單服務(wù):修改訂單的狀態(tài)為未支付
賬戶(hù)服務(wù):賬戶(hù)余額不變，可用余額變?yōu)?當(dāng)前值加凍結(jié)字段的值)，凍結(jié)字段清0。
庫(kù)存服務(wù):庫(kù)存不變，可銷(xiāo)售庫(kù)存變?yōu)?當(dāng)前值加凍結(jié)字段的值)，凍結(jié)字段清0。

偽代碼

接下來(lái)從代碼程序來(lái)說(shuō)明，為了便于演示，將入?yún)⒙匀ァ?br/>本來(lái)，你支付服務(wù)的代碼是長(zhǎng)下面這樣的

那么，用上TCC模型后，代碼變成下面這樣

注意了，這種寫(xiě)法其實(shí)嚴(yán)格上來(lái)說(shuō)，不是不行?？茨銟I(yè)務(wù)場(chǎng)景，因?yàn)榇嬖谝恍╄Υ?，看你自己有沒(méi)辦法接受
(1)cancel或者confirm出現(xiàn)異常了，你怎么處理？
例如在cancel階段執(zhí)行如下三行代碼

orderClient.cancelUpdateStatus();
accountClient.cancelDecrease();
repositoryClient.cancelDecrease();

你第二行出現(xiàn)異常了，第三行沒(méi)跑就退出了，怎么辦？你要對(duì)此進(jìn)行業(yè)務(wù)補(bǔ)償！
(2)大量邏輯重復(fù)
你看啊，我們的執(zhí)行架構(gòu)其實(shí)是這樣的

try{
    xxclient.try();
}catch(Throwable t){
    xxclient.cancel();
    throw t;
}
xxclient.confirm();

有沒(méi)辦法讓這個(gè)架子交給框架去執(zhí)行，我們告訴框架，你在每個(gè)階段要執(zhí)行哪些方法就好！

因此，需要引入TCC分布式事務(wù)框架，事務(wù)的Try、Confirm、Cancel三個(gè)狀態(tài)交給框架來(lái)感知！你只要告訴框架，Try要執(zhí)行啥，Confirm要執(zhí)行啥，Cancel要執(zhí)行啥!如果Cancel過(guò)程出現(xiàn)異常了，框架有內(nèi)部的補(bǔ)償措施給你恢復(fù)數(shù)據(jù)！
以分布式tcc框架hmily為例，如果出現(xiàn)cancel異?；蛘遚onfirm異常的情況，在try階段會(huì)保存好日志，Hmily有內(nèi)置的調(diào)度線程池來(lái)進(jìn)行恢復(fù)，不用擔(dān)心。
那hmily，怎么感知狀態(tài)的呢？也很簡(jiǎn)單，就是切面編程，核心邏輯如下幾行

我們?cè)谑褂眠^(guò)程中，只要通過(guò)@Tcc注解告訴框架confirm方法執(zhí)行啥，cancel方法執(zhí)行啥即可！其他的交給框架幫你處理！
好了，不多說(shuō)了，再說(shuō)下去就是hmily源碼解析了，大家有空自己去了解！

挖坑

那如果碰到，不同平臺(tái)之間調(diào)用，你要怎么保證事務(wù)？比如，我的服務(wù)要調(diào)銀行接口，你覺(jué)得可能讓銀行接你的tcc框架么？或者讓銀行接你的消息對(duì)列？你們覺(jué)得現(xiàn)實(shí)么？當(dāng)然，有的人會(huì)說(shuō):"一個(gè)http直接調(diào)了。"嗯，少年有想法！
ok，那么業(yè)內(nèi)針對(duì)這種涉及到第三方接口的服務(wù)調(diào)用，如何保證一致性？大家好好思考。