tcc事務是try、commit、cancel三種指令的縮寫，其邏輯模式類似於xa兩階段提交，但是實現方式是在**層面來人為實現。
tcc開源框架bytetcc，tcc-transaction，himly
1、先來try一下，不要把業務邏輯完成，先試試看，看各個服務能不能基本正常運轉，能不能先凍結我需要的資源。如果try都ok，也就是說，底層的資料庫、redis、elasticsearch、mq都是可以寫入資料的，並且你保留好了需要使用的一些資源（比如凍結了一部分庫存）。
2、再執行各個服務的confirm邏輯，基本上confirm就可以很大概率保證乙個分布式事務的完成了。
3、如果try或confirm 失敗了。則把之前的try邏輯都回滾，所有服務都不要執行任何設計的業務邏輯。保證大家要麼一起成功，要麼一起失敗。
示例：下單減庫存的方案[偽**]
單機服務各個系統都在同一臺伺服器上，可以直接執行以下偽**，本地事務保證資料一致性，任何一步異常則回滾整個事務
訂單系統：下單
支付系統：支付[成功]
優惠券系統：扣減優惠券
庫存系統：減庫存
使用者系統：增加使用者積分
try階段：
訂單系統：下單
優惠券系統：先凍結優惠券
庫存系統：先預佔庫存
使用者系統：先預增加使用者積分
支付系統：支付[成功]
優惠券系統：解凍優惠券-真正扣減優惠券
庫存系統：釋放預佔庫存-真正減庫存
使用者系統：回滾預增加的使用者積分-真正增加使用者積分
支付系統：支付[失敗]
優惠券系統：解凍優惠券
庫存系統：釋放預佔庫存
使用者系統：回滾預增加的使用者積分
tcc分布式事務 分布式事務之TCC事務模型
我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修改訂單狀態 2 賬戶服務 扣減金錢 3 庫存服務 扣減庫存 達到事務的效果，要麼一起成功，要麼一起失敗！就要採取tcc分布式事務方案！tcc的全稱是 try confirm canc...
TCC 分布式事務
高可用 背景 case零 tcc問題 庫存服務 並未扣減庫存數量 case一 正確情況 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫存數量 成功 3 積分服務 增加會員積分 成功 4 倉儲服務 建立出庫單據 成功 case二 錯誤回滾 1 訂單服務 修改訂單狀態 成功 2 庫存服務 扣減庫...
分布式事務之TCC
假設現在有乙個電商系統，裡面有乙個支付訂單的場景。對乙個訂單進行支付之後，我們需要做下面的步驟 以上業務場景對應下面的 public class orderservice tcc是try confirm cancel的簡稱 try 階段 嘗試執行，完成所有業務檢查 一致性 預留必需業務資源 準隔離性...