引言

在上篇文章《老生常談——利用訊息佇列處理分散式事務》一文中留了一個坑，今天來填坑。如下圖所示

如果服務A和服務B之間是同步呼叫，比如服務C需要按流程調服務A和服務B，服務A和服務B要麼一起成功，要麼一起失敗。
針對這種情況，目前業內普遍推薦使用TCC事務來解決的！

正文

ok,老規矩，我們先套一個業務場景進去，如下圖所示

那頁面點了支付按鈕，呼叫支付服務，那我們後臺要實現下面三個步驟
[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階段
訂單服務:修改訂單的狀態為支付完成

虛擬碼

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

那麼，用上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，那麼業內針對這種涉及到第三方介面的服務呼叫，如何保證一致性？大家好好思考。