如果服務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()；
具體每個階段，每個服務業務邏輯是什麼樣的呢?
假設，庫存數量本來是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)大量邏輯重複
你看啊，我們的執行架構其實是這樣的
trycatch(throwable t)
xxclient.confirm();
因此，需要引入tcc分布式事務框架，事務的try、confirm、cancel三個狀態交給框架來感知！你只要告訴框架，try要執行啥，confirm要執行啥，cancel要執行啥!如果cancel過程出現異常了，框架有內部的補償措施給你恢復資料！
以分布式tcc框架hmily為例，如果出現cancel異常或者confirm異常的情況，在try階段會儲存好日誌，hmily有內建的排程執行緒池來進行恢復，不用擔心。
那hmily，怎麼感知狀態的呢？也很簡單，就是切面程式設計，核心邏輯如下幾行
我們在使用過程中，只要通過@tcc註解告訴框架confirm方法執行啥，cancel方法執行啥即可！其他的交給框架幫你處理！
好了，不多說了，再說下去就是hmily原始碼解析了，大家有空自己去了解！
tcc分布式事務 分布式事務之TCC事務模型
我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修改訂單狀態 2 賬戶服務 扣減金錢 3 庫存服務 扣減庫存 達到事務的效果，要麼一起成功，要麼一起失敗！就要採取tcc分布式事務方案！tcc的全稱是 try confirm canc...
分布式事務之TCC
假設現在有乙個電商系統，裡面有乙個支付訂單的場景。對乙個訂單進行支付之後，我們需要做下面的步驟 以上業務場景對應下面的 public class orderservice tcc是try confirm cancel的簡稱 try 階段 嘗試執行，完成所有業務檢查 一致性 預留必需業務資源 準隔離性...
TCC 分布式事務
高可用 背景 case零 tcc問題 庫存服務 並未扣減庫存數量 case一 正確情況 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫存數量 成功 3 積分服務 增加會員積分 成功 4 倉儲服務 建立出庫單據 成功 case二 錯誤回滾 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫...