老焦專欄 | 為什麼需要用業務補償服務和TCC 型服務實現資料一致性

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

分散式事務解決的問題很明確，就是在服務分佈在不同程式、資料分佈在不同資料庫時，如何解決資料一致性問題。對於這個問題，業界的共識是不要啟用資料庫 XA 模式，因為分散式情況下，如果啟用了 XA 事務，必然會有資料庫鎖存在，實際上造成了兩個服務之間的耦合，與分散式服務的初衷背離，還不如部署在一起。在不使用 XA 的情況下，經常使用業務補償和TCC（Try/Confirm/Cancel）模式的服務來解決：為什麼有這樣兩種模式呢，他們有什麼區別，各自適合什麼樣的場景，這兩種模式是否帶來了程式碼開發的複雜度？經常有人問我這樣的問題，這裡簡單說明一下：

用補償交易保證資料一致性

解決資料一致性問題，可以透過業務補償的方式完成。實際上業務補償是一種業務提出的要求，在銀行我們可以把交易（服務）分為賬務類和查詢類交易（在這裡服務和交易是等同的，我就不再專門區分了），對於賬務類交易，可以提供補償交易，一旦業務失敗可以呼叫補償交易，透過沖正等方式進行，如何補償在業務上是有明確定義的，不能隨意而為。（不要擔心這樣做開發起來複雜了，這是必須做的需求）。

當年很多業務在失敗的時候，是由人工發起補償交易的（我在阿里展覽館就要這樣的展品，在一個小本本上手工記錄的交易金額、流水號等，早期的支付寶就是這樣衝正的）。這樣做法效率低，我們就希望能夠透過技術手段，在業務失敗的時候自動發起補償交易，減少人工參與。為此，我們可以開發一個自動補償的框架，記錄每個處理過的業務交易流水，在處理某個交易失敗的時候，依次呼叫補償交易，流程如下：

TCC服務（交易）的使用場景

銀行的賬務類交易除了補償類交易之外，還有一種 TCC 型別的服務，這類交易的 T 是 Try 的一起，也就是開始時預留資源，在 Confirm 的時候改變最終資源，或者在 Cancel 的時候釋放預留資源。例如，在銀行賬目中，都有餘額和可用餘額兩個欄位，在 T 的時候，首先改變可用餘額，業務上用可用餘額來進行判斷，而不是用實際餘額判斷，在 Confirm 的時候，修改實際餘額，在 Cancel 的時候，修改可用餘額。

這樣做的好處是，在業務失敗的情況下，實際餘額不會出現變化。我經常遇到的問題是：

1. 有了補償服務為什麼還要 TCC，有什麼好處，為什麼不能直接修改賬戶餘額；

2. TCC 服務要用什麼樣的框架實現。

TCC 這種做法有什麼好處

以前面賬戶餘額和可用餘額的例子看，賬戶餘額的調整會涉及到很多方面，不僅僅是一個欄位數值的更新，根據會計原則，賬戶餘額的變化需要生成會計分錄、登記賬務流水、計算利率變化、計算稅率變化等等，除此之外，賬戶餘額的變化還會引起關聯賬戶的變化，牽一髮動全身。在業務失敗的時候，如果呼叫補償交易，就需要對上述操作做處理，業務處理太複雜，得不償失。因此，一般會設計一個可用餘額，首先改變可用餘額，業務成功時再調整賬戶實際餘額。根據這個示例，我們也可以清楚，在什麼場景下需要 TCC 服務了。其實，在金融交易中，就有專門的預付費交易，就可以用來支援 TCC 模式。

（點選圖片可放大）

TCC 服務要用什麼樣的框架實現？

從上述示例可以看出，TCC和補償式交易一樣，都是為了滿足業務的要求，而這些交易恰好可以用來為資料一致性服務，TCC服務的 T、C、C實現，完全是根據業務需要實現，不可能有一個統一的實現框架，例如賬戶餘額的做法和庫存餘額的做法，可能是差距很大的，沒有必要抽象出來。網際網路上雖然有實現 TCC 服務的方式，但是也都是針對特定業務的，不具備通用型。

但是，為什麼往往有人提出，框架要支援 TCC 呢，究其原因是把 TCC 服務和資料一致性框架混為一談了，前者是一個服務實現，後者是利用服務的特點保證資料完整性，減少人工操作。

資料一致性框架，除了利用 TCC/補償服務的框架之外，還有利用冪等服務特性實現的重試性框架，也就是利用交易的冪等特性，反覆進行重試，如果多次重試還是不成功，只有採用人工手段了。

總結一下：

---

補償類服務和 TCC 服務是處理重要資訊變更的兩種模式，可以透過這兩種模式，來支援資料一致性。這兩種方式都是特定業務的需要，而不是 XA事務、重試這樣，用一種技術手段實現資料一致性。對於簡單的業務來說，這兩種方式是沒有必要的，但是對於重要資訊的變更，尤其是分散式系統從渠道、中臺、核心多環節完成資訊變更時，這是必須的。

關於作者：焦烈焱，普元資訊CTO，致力於技術創新和金融創新解決方案研究。專注於企業技術架構領域，對分散式環境的企業計算、 企業資訊架構的規劃與實踐有著豐厚經驗，帶領普元技術團隊相繼在雲端計算、大資料及移動開發領域取得多項突破，並主持中國工商銀行、中國建設銀行等多家大型企業技術平臺的規劃與研發。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。