概念

TCC 又稱補償事務。其核心思想是：?" 針對每個操作都要注冊一個與其對應的確認和補償（撤銷）操作 "。它分為三個操作：

Try 階段：主要是對業務系統做檢測及資源預留。

Confirm 階段：確認執行業務操作。

Cancel 階段：取消執行業務操作。

TCC 對應?Try、Confirm、Cancel?三種操作可以理解成關系型數據庫事務的三種操作：DML、Commit、Rollback。

?

在一個跨應用的業務操作中

Try：Try 操作是先把多個應用中的 業務資源預留?和?鎖定，為后續的確認打下基礎，類似的，DML 操作要鎖定數據庫記錄行，持有數據庫資源。

Confirm：Confirm 操作是在 Try 操作中涉及的所有應用均成功之后進行確認，使用預留的業務資源，和 Commit 類似。

Cancel：Cancel 則是當 Try 操作中涉及的所有應用沒有全部成功，需要將已成功的應用進行取消（即 Rollback?）。其中?Confirm?和?Cancel?操作是一對反向業務操作。

?

TCC 的具體原理如下：

從圖中我們可以明顯看到?Confirm?和?Cancel?操作是一對反向業務操作，即要?Try 返回成功執行?Confirm，要么?Try?返回失敗執行?Cancel?操作。

分布式事務協調者：管理控制整個業務活動，包括記錄維護?TCC?全局事務的事務狀態和每個從業務服務的子事務狀態，并在業務活動提交時確認所有的?TCC?型操作的?Confirm?操作，在業務活動取消時調用所有?TCC 型操作的?Cancel?操作。

?

?

舉例

例子：A服務 轉 30 塊錢、B服務 轉 50 塊錢，一起到 C 服務上。

Try（嘗試執行業務）：完成所有業務檢查，檢查 A、B、C 的帳戶狀態是否正常，帳戶A 的余額是否不少于 30 元，帳戶B 的余額是否不少于 50 元。預留必須的業務資源（準隔離性）：帳戶A 的凍結金額增加 30 元，帳戶B 的凍結金額增加 50 元，這樣就保證不會出現其他并發進程扣減了這兩個帳戶的余額而導致在后續的真正轉帳操作過程中，帳戶 A 和 B 的可用余額不夠的情況。

Confirm（確認執行業務）：真正執行業務，如果?Try?階段帳戶 A、B、C 狀態正常，且帳?A、B 余額夠用，則執行 帳戶A?給?賬戶C?轉賬 30 元、帳戶B?給 賬戶C 轉賬 50 元的轉帳操作。這時已經不需要做任何業務檢查，Try?階段已經完成了業務檢查。只使用?Try?階段預留的業務資源，即?Try?階段 帳戶A?和 帳戶B 凍結的金額。

Cancel（取消執行業務）：釋放?Try?階段預留的業務資源，如果?Try?階段部分成功，比如?帳戶A?的余額夠用，且凍結相應金額成功，帳戶B?的余額不夠而凍結失敗，則需要對?帳戶A?做?Cancel?操作，將?帳戶A 被凍結的金額解凍掉。

?

?

TCC 和 2PC 比較

2PC 是資源層面的分布式事務，強一致性，在兩階段提交的整個過程中，一直會持有資源的鎖。

XA 事務中的兩階段提交內部過程是對開發者屏蔽的，事務管理器在兩階段提交過程中，從 prepare?到?commit/rollback?過程中，資源實際上一直都是被加鎖的。如果有其他人需要更新這兩條記錄，那么就必須等待鎖釋放。

?

TCC 是業務層面的分布式事務，最終一致性，不會一直持有資源的鎖。

當執行?Try 接口的時候，已經把所需的資源給預扣了，比如上面舉例的 A服務 已經預扣 30 元，B服務 已經預扣 50 元，它是由?Try 接口實現，這樣就保證不會出現其他并發進程扣減了這兩個帳戶的余額而導致在后續的真正轉帳操作過程中，帳戶 A 和 B 的可用余額不夠的情況，同時保證不會一直鎖住整個資源。

TCC中的兩階段提交并沒有對開發者完全屏蔽，也就是說從代碼層面，開發者是可以感受到兩階段提交的存在。

(1) Try 過程的本地事務，是保證資源預留的業務邏輯的正確性。

(2) Confirm/Cancel 執行的本地事務邏輯確認/取消預留資源，以保證最終一致性，也就是所謂的補償型事務。

由于是多個獨立的本地事務，因此不會對資源一直加鎖。

?

?

原文：https://www.cnblogs.com/qdhxhz/p/11172585.html

總結

以上是生活随笔為你收集整理的分布式事务——TCC 原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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