我們先套乙個業務場景進去，如下圖所示
那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟
[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框架麼？或者讓銀行接你的訊息對列？你們覺得現實麼？當然，有的人會說:"乙個http直接調了。"嗯，少年有想法！
TCC 分布式事務
高可用 背景 case零 tcc問題 庫存服務 並未扣減庫存數量 case一 正確情況 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫存數量 成功 3 積分服務 增加會員積分 成功 4 倉儲服務 建立出庫單據 成功 case二 錯誤回滾 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫...
分布式事務之TCC
假設現在有乙個電商系統，裡面有乙個支付訂單的場景。對乙個訂單進行支付之後，我們需要做下面的步驟 以上業務場景對應下面的 public class orderservice tcc是try confirm cancel的簡稱 try 階段 嘗試執行，完成所有業務檢查 一致性 預留必需業務資源 準隔離性...
分布式事務之TCC
如果服務a和服務b之間是同步呼叫，比如服務c需要按流程調服務a和服務b，服務a和服務b要麼一起成功，要麼一起失敗。針對這種情況，目前業內普遍推薦使用tcc事務來解決的！ok,老規矩，我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修...