高可用
背景
case零 tcc問題
庫存服務 並未扣減庫存數量
case一 正確情況
[1]訂單服務 修改訂單狀態-成功
[2]庫存服務 扣減庫存數量-成功
[3]積分服務 增加會員積分-成功
[4]倉儲服務 建立出庫單據-成功
case二 錯誤回滾
[1]訂單服務 修改訂單狀態-成功
[2]庫存服務 扣減庫存數量-失敗
[3]積分服務 增加會員積分-取消執行
[4]倉儲服務 建立出庫單據-取消執行
[5]訂單服務 修改訂單狀態-撤銷操作
應用框架 bytetcc、himly、tcc-transaction
三個階段
[1]try
[2]confirm
[3]cancel
呼叫邏輯
[1]首先 預備服務 try
[2]正確 確認服務 confirm
[3]錯誤 取消服務 cancel
訂單服務 修改狀態 orderdao.updatestatus(orderstatus.payed)； 已支付
庫存服務 扣減庫存 inventoryservice.reducestock()； 扣減
積分服務 增加積分 creditservice.addcredit()；
倉儲服務 通知出庫 wmsservice.saledelivery()；
目的 鎖定資源、設定預備狀態、凍結部分資料
訂單服務 修改狀態 orderdao.updatestatus(orderstatus.updating)； 修改中
庫存服務 扣減庫存 凍結
積分服務 增加積分 prepareaddcredit 預增
倉儲服務 通知出庫 unknown 未知
訂單服務 確認服務 orderserviceconfirm orderdao.updatestatus(orderstatus.payed) 已支付
庫存服務 確認服務 inventoryserviceconfirm 扣減
積分服務 確認服務 creditserviceconfirm 增加
倉儲服務 確認服務 wmsserviceconfirm 建立
訂單服務 取消服務 orderservicecancel canceled 已取消
庫存服務 取消服務 inventoryservicecancel 回加數值
積分服務 取消服務 creditservicecancel 扣減數值
倉儲服務 取消服務 wmsservicecancel canceled 已取消
支服務宕機 t解決
主服務宕機 tcc框架 記錄活動日誌：
[1]支服務-第一階段，執行失敗 try預備階段 cancel階段取消服務
資料庫宕機
基礎設施宕機 redis、elasticsearch、mq
服務執行失敗
[2]主服務執行失敗 tcc框架，記錄活動日誌
[3]支服務-第二階段，不斷執行失敗 confirm確認階段、cancel取消階段 tcc框架，記錄活動日誌
tcc分布式事務 分布式事務之TCC事務模型
我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修改訂單狀態 2 賬戶服務 扣減金錢 3 庫存服務 扣減庫存 達到事務的效果，要麼一起成功，要麼一起失敗！就要採取tcc分布式事務方案！tcc的全稱是 try confirm canc...
分布式事務之TCC
假設現在有乙個電商系統，裡面有乙個支付訂單的場景。對乙個訂單進行支付之後，我們需要做下面的步驟 以上業務場景對應下面的 public class orderservice tcc是try confirm cancel的簡稱 try 階段 嘗試執行，完成所有業務檢查 一致性 預留必需業務資源 準隔離性...
分布式事務之TCC
如果服務a和服務b之間是同步呼叫，比如服務c需要按流程調服務a和服務b，服務a和服務b要麼一起成功，要麼一起失敗。針對這種情況，目前業內普遍推薦使用tcc事務來解決的！ok,老規矩，我們先套乙個業務場景進去，如下圖所示 那頁面點了支付按鈕，呼叫支付服務，那我們後台要實現下面三個步驟 1 訂單服務 修...