分佈式事務 Seata-TCC 事務模式

通用TCC模式

TCC 是二階段提交協議，Try-Confirm-Cancel（資源預留、確認操作、取消操作），Try 是對當前業務資源的檢查，如果成功，則 Confirm 提交，否則 Cancel 回滾。

這三個操作都需要自定義實現業務邏輯，這也是 TCC 和其他的事務模式不同的地方。

XA 和 AT 都是依賴本地數據庫事務進行的分佈式事務的執行，而 TCC 完全不依賴數據庫，對業務有非常大的侵入性，因爲需要自定義實現這三個接口邏輯：實現 Try（對業務資源的檢查邏輯），Confirm（Try 成功後的提交邏輯），Cancel（出現問題的回滾邏輯）。

好處是不依賴數據庫，可以跨數據庫、跨應用資源，管理這些對不同數據訪問侵入式編碼方式實現的原子操作，解決各種複雜場景下的分佈式問題。

TCC 在金融業務場景下用的比較多。

業務應用是 TM，負責開啓全局事務，事務協調器是 TC，服務 A 和服務 B 是 RM。

業務應用開啓全局事務，具體的服務（比如服務 A、B）需要實現實現 Try、Confirm、Cancel 三個接口邏輯。

業務應用開啓全局事務，調用每個服務的 Try 接口，Try 沒有問題，則調用具體服務的 Confirm 進行提交或調用 Cancel 進行回滾。

假設服務 A Try 沒有問題，服務 B 出現了問題，則調用 Cancel 接口，如果有一個服務出現問題就需要全局回滾，由事務協調器發起調用服務 A 的 Cancel 接口和調用服務 B 的 Cancel 接口進行回滾，這就是 TCC 的整體邏輯。

Seata TCC模式

Seata TCC 模式和通用 TCC 模式原理一樣。

所謂的 TCC 模式是把自定義的分支事務納入全局事務中管理。

TCC 和 AT 都是二階段，AT 支持本地事務的 ACID（關係型數據庫），在一階段，會記錄本地事務對數據的更新和記錄更新之前的數據到日誌 undolog（數據快照）中。

第二階段，如果沒有問題，則提交事務和清理日誌，若出現問題，則回滾，自動補償、清理日誌、釋放資源。

TCC 不依賴底層數據庫資源的支持，所以在第一階段，需要調用自己實現的 Try 接口裏面的邏輯，比如銀行提交扣款請求。

第一階段沒有問題的話，則第二階段進行提交，如果第一階段出現問題了，則第二階段調用 rollback 進行回滾。

TCC 侵入性比較強，需要自己實現相關的業務邏輯，但在整個過程中是沒有鎖的。

AT 是有鎖的，爲了防止髒讀和髒寫。

下單請求給到事務協調者，首先調用訂單服務 Try 方法執行下單中的邏輯，然後調用庫存服務，鎖定庫存，事務協調者如果沒有收到問題反饋，就調用每個具體服務的 Confirm，即調用訂單服務 Confirm 執行支付邏輯，調用庫存服務 Confirm 執行扣減庫存的邏輯，如果扣減庫存出問題了，就調用訂單服務的 Concel 執行未支付或回滾的邏輯。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/c_1lcunSF1ghOGkaOiVtiQ