嚴格遵守acid的分布式事務我們稱為剛性事務，而遵循base理論（基本可用：在故障出現時保證核心功能可用，軟狀態：允許中間狀態出現，最終一致性：不要求分布式事務打成中時間點資料都是一致性的，但是保證達到某個時間點後，資料就處於了一致性了）的事務我們稱為柔性事務，其中tcc程式設計模式就屬於柔性事務，本文我們來闡述其理論。
tcc程式設計模式本質上也是一種二階段協議，不同在於tcc程式設計模式需要與具體業務耦合，下面首先看下tcc程式設計模式步驟:
螞蟻金服基於tcc實現了xts（雲上叫dts），目前在螞蟻金服雲上有對外輸出，這裡我們來結合其提供的乙個例子來具體理解tcc的含義，以下引入螞蟻金服雲例項：
「首先我們假想這樣一種場景：轉賬服務，從銀行 a 某個賬戶轉 100 元錢到銀行 b 的某個賬戶，銀行 a 和銀行 b 可以認為是兩個單獨的系統，也就是兩套單獨的資料庫。
我們將賬戶系統簡化成只有賬戶和餘額 2 個字段，並且為了適應 dts 的兩階段設計要求，業務上又增加了乙個凍結金額（凍結金額是指在一筆轉賬期間，在一階段的時候使用該欄位臨時儲存轉賬金額，該轉賬額度不能被使用，只有等這筆分布式事務全部提交成功時，才會真正的計入可用餘額）。按這樣的設計，使用者的可用餘額等於賬戶餘額減去凍結金額。這點是理解參與者設計的關鍵，也是 dts 保證最終一致的業務約束。」
在try階段並沒有對銀行a和b資料庫中的餘額欄位做操作，而是對凍結金額做的操作，對應a銀行預留資源操作是對凍結金額加上100元，這時候a銀行賬號上可用錢為餘額欄位-凍結金額；對應b銀行的操作是對凍結金額上減去100，這時候b銀行賬號上可用的錢為餘額欄位-凍結金額。
如果事務協調器呼叫銀行a和銀行b的try方法有乙個失敗了（比如銀行a的賬戶餘額不夠了），則呼叫cancle進行回滾操作（具體是對凍結金額做反向操作）。如果呼叫try方法都ok了，則進入confirm階段，confirm階段則不做資源檢查，直接做業務操作，對應銀行a要在賬戶餘額減去100，然後凍金額減去100；對應銀行b要對賬戶餘額字段加上100，然後凍結金額加上100。
最關心的，如果confirm階段如果有乙個參與者失敗了，該如何處理，其實上面操作都是xts-client做的，還有乙個xts-server專門做事務補償的。
tcc是對二階段的乙個改進，try階段通過預留資源的方式避免了同步阻塞資源的情況，但是tcc程式設計需要業務自己實現try,confirm,cancle方法，對業務入侵太大，實現起來也比較複雜。
更多關於分布式系統中服務降級策略的知識可以單擊 單擊我
想系統學dubbo的單擊我
想學併發的童鞋可以 單擊我
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 階段 嘗試執行，完成所有業務檢查 一致性 預留必需業務資源 準隔離性...