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

EAWorld發表於2019-05-31

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

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

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

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

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

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

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

TCC服務(交易)的使用場景

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

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

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

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

TCC 這種做法有什麼好處

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

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

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

(點選圖片可放大)

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

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

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

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

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



總結一下:


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


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

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

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562043/viewspace-2646395/,如需轉載,請註明出處,否則將追究法律責任。

相關文章