分布式事務之TCC事務模型

正文

我們先套一個業務場景進去，如下圖所示

那頁面點了支付按鈕，調用支付服務，那我們后臺要實現下面三個步驟
[1] 訂單服務-修改訂單狀態
[2] 賬戶服務-扣減金錢
[3] 庫存服務-扣減庫存
達到事務的效果，要么一起成功，要么一起失敗！就要采取TCC分布式事務方案！

概念

TCC的全稱是（Try-Confirm-Cancel）。如下圖所示

ps:TCC又可以被稱為兩階段補償事務，第一階段try只是預留資源，第二階段要明確的告訴服務提供者，這個資源你到底要不要，對應第二階段的confirm/cancel，用來清除第一階段的影響，所以叫補償型事務。

再打個比方，說TCC太高大上是吧，講RM中的prepare、commit、rollback接口，總知道吧。可以類比的這么理解

那差別在哪呢?
rollback、commit、prepare，站在開發者層面是感知不到的，數據庫幫你做了資源的操作!
而try、confirm、cancel，站在開發者層面是能感知到的，這三個方法的業務邏輯，即對資源的操作，開發者是要自己去實現的！
好，下面套入我們的場景，怎么做呢。比如，你的訂單服務中本來只有一個接口

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

都要拆為三個接口，即

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

注意了：面試官如果問你，TCC有什么缺點？這就是很嚴重的缺點，對代碼***性大！每套業務邏輯、都要按try(請求資源)、confirm(操作資源)、cancel(取消資源)，拆分為三個接口！

具體每個階段，每個服務業務邏輯是什么樣的呢?
假設，庫存數量本來是50，那么可銷售庫存也是50。賬戶余額為50,可用余額也為50。用戶下單，買了1個單價為1元的商品。流程如下:
Try階段
訂單服務:修改訂單的狀態為支付中
賬戶服務:賬戶余額不變，可用余額減1，然后將1這個數字凍結在一個單獨的字段里
庫存服務:庫存數量不變，可銷售庫存減1，然后將1這個數字凍結在一個單獨的字段里
confirm階段
訂單服務:修改訂單的狀態為支付完成
賬戶服務:賬戶余額變為(當前值減凍結字段的值)，可用余額不變(Try階段減過了),凍結字段清0。
庫存服務:庫存變為(當前值減凍結字段的值)，可銷售庫存不變(Try階段減過了)，凍結字段清0。
cancel階段
訂單服務:修改訂單的狀態為未支付
賬戶服務:賬戶余額不變，可用余額變為(當前值加凍結字段的值)，凍結字段清0。
庫存服務:庫存不變，可銷售庫存變為(當前值加凍結字段的值)，凍結字段清0。

偽代碼

接下來從代碼程序來說明，為了便于演示，將入參略去。
本來，你支付服務的代碼是長下面這樣的

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

注意了，這種寫法其實嚴格上來說，不是不行。看你業務場景，因為存在一些瑕疵，看你自己有沒辦法接受
(1)cancel或者confirm出現異常了，你怎么處理？
例如在cancel階段執行如下三行代碼

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

你第二行出現異常了，第三行沒跑就退出了，怎么辦？你要對此進行業務補償！
(2)大量邏輯重復
你看啊，我們的執行架構其實是這樣的

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

有沒辦法讓這個架子交給框架去執行，我們告訴框架，你在每個階段要執行哪些方法就好！

因此，需要引入TCC分布式事務框架，事務的Try、Confirm、Cancel三個狀態交給框架來感知！你只要告訴框架，Try要執行啥，Confirm要執行啥，Cancel要執行啥!如果Cancel過程出現異常了，框架有內部的補償措施給你恢復數據！
以分布式tcc框架hmily為例，如果出現cancel異常或者confirm異常的情況，在try階段會保存好日志，Hmily有內置的調度線程池來進行恢復，不用擔心。
那hmily，怎么感知狀態的呢？也很簡單，就是切面編程，核心邏輯如下幾行

我們在使用過程中，只要通過@Tcc注解告訴框架confirm方法執行啥，cancel方法執行啥即可！其他的交給框架幫你處理！
好了，不多說了，再說下去就是hmily源碼解析了，大家有空自己去了解！

挖坑

那如果碰到，不同平臺之間調用，你要怎么保證事務？比如，我的服務要調銀行接口，你覺得可能讓銀行接你的tcc框架么？或者讓銀行接你的消息對列？你們覺得現實么？當然，有的人會說:"一個http直接調了。"嗯，少年有想法！
ok，那么業內針對這種涉及到第三方接口的服務調用，如何保證一致性？大家好好思考。