補償事務（TCC）

TCC 將事務提交分為 Try(method1) - Confirm(method2) - Cancel(method3) 3個操作。其和兩階段提交有點類似，Try為第一階段，Confirm - Cancel為第二階段，是一種應用層面侵入業務的兩階段提交。

操作方法含義

Try	預留業務資源/數據效驗
Confirm	確認執行業務操作，實際提交數據，不做任何業務檢查，try成功，confirm必定成功，需保證冪等
Cancel	取消執行業務操作，實際回滾數據，需保證冪等

其核心在于將業務分為兩個操作步驟完成。不依賴 RM 對分布式事務的支持，而是通過對業務邏輯的分解來實現分布式事務。

例如： A要向 B 轉賬，思路大概是：

我們有一個本地方法，里面依次調用?
1、首先在 Try 階段，要先調用遠程接口把 B和 A的錢給凍結起來。?
2、在 Confirm 階段，執行遠程調用的轉賬的操作，轉賬成功進行解凍。?
3、如果第2步執行成功，那么轉賬成功，如果第二步執行失敗，則調用遠程凍結接口對應的解凍方法 (Cancel)。?

假設用戶user表中有兩個字段：可用余額(available_money)、凍結余額(frozen_money)
A扣錢對應服務A(ServiceA)
B加錢對應服務B(ServiceB)
轉賬訂單服務(OrderService)
業務轉賬方法服務(BusinessService)

ServiceA，ServiceB，OrderService都需分別實現try()，confirm()，cancle()方法，方法對應業務邏輯如下

操作方法ServiceAServiceBOrderService

try()	校驗余額(并發控制)<br/>凍結余額+1000<br/>余額-1000	凍結余額+1000	創建轉賬訂單，狀態待轉賬
confirm()	凍結余額-1000	?	狀態變為轉賬成功
cancle()	凍結余額-1000<br/>余額+1000	?	狀態變為轉賬失敗

其中業務調用方BusinessService中就需要調用ServiceA.try()ServiceB.try()OrderService.try()

1、當所有try()方法均執行成功時，對全局事物進行提交，即由事物管理器調用每個微服務的confirm()方法

2、 當任意一個方法try()失敗(預留資源不足，抑或網絡異常，代碼異常等任何異常)，由事物管理器調用每個微服務的cancle()方法對全局事務進行回滾

?

優點： 跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些

缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，在一些場景中，一些業務流程可能用TCC不太好定義及處理。

?

總結

以上是生活随笔為你收集整理的TCC事务补偿机制实现分布式事务控制介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。