假設現在有乙個電商系統，裡面有乙個支付訂單的場景。
對乙個訂單進行支付之後，我們需要做下面的步驟：
以上業務場景對應下面的**：
public class orderservice
}
try 階段：嘗試執行，完成所有業務檢查（一致性），預留必需業務資源（準隔離性）。
confirm 階段：確認真正執行業務，不作任何業務檢查，只使用 try 階段預留的業務資源，confirm 操作滿足冪等性。要求具備冪等設計，confirm 失敗後需要進行重試。
總結一下，你要玩 tcc 分布式事務的話：首先需要選擇某種 tcc 分布式事務框架，各個服務裡就會有這個 tcc 分布式事務框架在執行。
然後原本的乙個介面，要改造為 3 個邏輯，try-confirm-cancel：
先是服務呼叫鏈路依次執行 try 邏輯。
如果都正常的話，tcc 分布式事務框架推進執行 confirm 邏輯，完成整個事務。
如果某個服務的 try 邏輯有問題，tcc 分布式事務框架感知到之後就會推進執行各個服務的 cancel 邏輯，撤銷之前執行的各種操作。
問題1：如果有一些意外的情況發生了，比如說訂單服務突然掛了，然後再次重啟，tcc 分布式事務框架是如何保證之前沒執行完的分布式事務繼續執行的呢？
所以，tcc 事務框架都是要記錄一些分布式事務的活動日誌的，可以在磁碟上的日誌檔案裡記錄，也可以在資料庫裡記錄。儲存下來分布式事務執行的各個階段和狀態。
問題2：萬一某個服務的 cancel 或者 confirm 邏輯執行一直失敗怎麼辦呢？
tcc 事務框架會通過活動日誌記錄各個服務的狀態。舉個例子，比如發現某個服務的 cancel 或者 confirm 一直沒成功，會不停的重試呼叫它的 cancel 或者 confirm 邏輯，務必要它成功！
tcc分布式事務 分布式事務之TCC事務模型
我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修改訂單狀態 2 賬戶服務 扣減金錢 3 庫存服務 扣減庫存 達到事務的效果，要麼一起成功，要麼一起失敗！就要採取tcc分布式事務方案！tcc的全稱是 try confirm canc...
分布式事務之TCC
如果服務a和服務b之間是同步呼叫，比如服務c需要按流程調服務a和服務b，服務a和服務b要麼一起成功，要麼一起失敗。針對這種情況，目前業內普遍推薦使用tcc事務來解決的！ok,老規矩，我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修...
TCC 分布式事務
高可用 背景 case零 tcc問題 庫存服務 並未扣減庫存數量 case一 正確情況 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫存數量 成功 3 積分服務 增加會員積分 成功 4 倉儲服務 建立出庫單據 成功 case二 錯誤回滾 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫...