正文

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

那頁面點了支付按鈕，呼叫支付服務，那我們後臺要實現下面三個步驟 [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，那麼業內針對這種涉及到第三方介面的服務呼叫，如何保證一致性？大家好好思考。