老焦專欄 | 為什麼需要用業務補償服務和TCC 型服務實現資料一致性
轉載本文需註明出處:微信公眾號EAWorld,違者必究。
分散式事務解決的問題很明確,就是在服務分佈在不同程式、資料分佈在不同資料庫時,如何解決資料一致性問題。對於這個問題,業界的共識是不要啟用資料庫 XA 模式,因為分散式情況下,如果啟用了 XA 事務,必然會有資料庫鎖存在,實際上造成了兩個服務之間的耦合,與分散式服務的初衷背離,還不如部署在一起。在不使用 XA 的情況下,經常使用業務補償和TCC(Try/Confirm/Cancel)模式的服務來解決:為什麼有這樣兩種模式呢,他們有什麼區別,各自適合什麼樣的場景,這兩種模式是否帶來了程式碼開發的複雜度?經常有人問我這樣的問題,這裡簡單說明一下:
用補償交易保證資料一致性
解決資料一致性問題,可以通過業務補償的方式完成。實際上業務補償是一種業務提出的要求,在銀行我們可以把交易(服務)分為賬務類和查詢類交易(在這裡服務和交易是等同的,我就不再專門區分了),對於賬務類交易,可以提供補償交易,一旦業務失敗可以呼叫補償交易,通過沖正等方式進行,如何補償在業務上是有明確定義的,不能隨意而為。(不要擔心這樣做開發起來複雜了,這是必須做的需求)。
當年很多業務在失敗的時候,是由人工發起補償交易的(我在阿里展覽館就要這樣的展品,在一個小本本上手工記錄的交易金額、流水號等,早期的支付寶就是這樣衝正的)。這樣做法效率低,我們就希望能夠通過技術手段,在業務失敗的時候自動發起補償交易,減少人工參與。為此,我們可以開發一個自動補償的框架,記錄每個處理過的業務交易流水,在處理某個交易失敗的時候,依次呼叫補償交易,流程如下:
TCC服務(交易)的使用場景
銀行的賬務類交易除了補償類交易之外,還有一種 TCC 型別的服務,這類交易的 T 是 Try 的一起,也就是開始時預留資源,在 Confirm 的時候改變最終資源,或者在 Cancel 的時候釋放預留資源。例如,在銀行賬目中,都有餘額和可用餘額兩個欄位,在 T 的時候,首先改變可用餘額,業務上用可用餘額來進行判斷,而不是用實際餘額判斷,在 Confirm 的時候,修改實際餘額,在 Cancel 的時候,修改可用餘額。
這樣做的好處是,在業務失敗的情況下,實際餘額不會出現變化。我經常遇到的問題是:
有了補償服務為什麼還要 TCC,有什麼好處,為什麼不能直接修改賬戶餘額;
TCC 服務要用什麼樣的框架實現。
TCC 這種做法有什麼好處
以前面賬戶餘額和可用餘額的例子看,賬戶餘額的調整會涉及到很多方面,不僅僅是一個欄位數值的更新,根據會計原則,賬戶餘額的變化需要生成會計分錄、登記賬務流水、計算利率變化、計算稅率變化等等,除此之外,賬戶餘額的變化還會引起關聯賬戶的變化,牽一髮動全身。在業務失敗的時候,如果呼叫補償交易,就需要對上述操作做處理,業務處理太複雜,得不償失。因此,一般會設計一個可用餘額,首先改變可用餘額,業務成功時再調整賬戶實際餘額。根據這個示例,我們也可以清楚,在什麼場景下需要 TCC 服務了。其實,在金融交易中,就有專門的預付費交易,就可以用來支援 TCC 模式。
(點選圖片可放大)
TCC 服務要用什麼樣的框架實現?
從上述示例可以看出,TCC和補償式交易一樣,都是為了滿足業務的要求,而這些交易恰好可以用來為資料一致性服務,TCC服務的 T、C、C實現,完全是根據業務需要實現,不可能有一個統一的實現框架,例如賬戶餘額的做法和庫存餘額的做法,可能是差距很大的,沒有必要抽象出來。網際網路上雖然有實現 TCC 服務的方式,但是也都是針對特定業務的,不具備通用型。
但是,為什麼往往有人提出,框架要支援 TCC 呢,究其原因是把 TCC 服務和資料一致性框架混為一談了,前者是一個服務實現,後者是利用服務的特點保證資料完整性,減少人工操作。
資料一致性框架,除了利用 TCC/補償服務的框架之外,還有利用冪等服務特性實現的重試性框架,也就是利用交易的冪等特性,反覆進行重試,如果多次重試還是不成功,只有採用人工手段了。
總結一下:
補償類服務和 TCC 服務是處理重要資訊變更的兩種模式,可以通過這兩種模式,來支援資料一致性。這兩種方式都是特定業務的需要,而不是 XA事務、重試這樣,用一種技術手段實現資料一致性。對於簡單的業務來說,這兩種方式是沒有必要的,但是對於重要資訊的變更,尤其是分散式系統從渠道、中臺、核心多環節完成資訊變更時,這是必須的。
關於作者:焦烈焱,普元資訊CTO,致力於技術創新和金融創新解決方案研究。專注於企業技術架構領域,對分散式環境的企業計算、 企業資訊架構的規劃與實踐有著豐厚經驗,帶領普元技術團隊相繼在雲端計算、大資料及移動開發領域取得多項突破,並主持中國工商銀行、中國建設銀行等多家大型企業技術平臺的規劃與研發。
關於EAWorld:微服務,DevOps,資料治理,移動架構原創技術分享。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562043/viewspace-2646395/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 老焦專欄 | 用 RACI 模式梳理業務流程,提高業務釋出的效率模式
- 產業服務是什麼意思?詳解產業服務產業
- 服務為什麼會崩潰
- 服務型企業的資源管理:助服務行業突破瓶頸!行業
- 服務型企業如何使用飛項實現專案化管理?
- NodeJs服務註冊與服務發現實現NodeJS
- 什麼是資料即服務(Data as a Service)?
- 什麼是能力、服務和功能?
- 業務能力、業務功能、業務流程、業務服務及業務模型到底有什麼區別?模型
- 什麼是抖音生活服務,都有哪些業務!
- 為什麼說資料服務是資料中臺的標配?
- 為什麼不要把ZooKeeper用於服務發現?
- 服務業CRM軟體能為你提供哪些服務?
- 使用SpringBoot構建REST服務-什麼是REST服務Spring BootREST
- 安全服務是什麼?安全服務產品包括哪些?
- 微服務分散式事務之LCN、TCC特點、事務補償機制緣由以及設計重點微服務分散式
- 什麼雲服務好呢
- IT服務管理是什麼?
- IDC服務是什麼?
- 華為雲災備服務,憑什麼能保護企業資料資產?
- 為什麼我要使得GOLang重寫SAAS(軟體即服務)服務端Golang服務端
- 華為帳號服務學習筆記(一):什麼是HMS,什麼是華為帳號服務筆記
- 2.8.1.2 資料庫服務和效能資料庫
- 資料服務怎麼掙錢?
- [翻譯]微服務設計模式 - 5. 服務發現 - 服務端服務發現微服務設計模式服務端
- 談談為什麼需要服務治理(Dubbo)
- SEO外包為什麼要收取服務費?
- 什麼是微服務架構?什麼是服務註冊與發現微服務架構
- C# 實現 gRPC 服務和呼叫C#RPC
- 分散式服務資料一致性-redis篇分散式Redis
- 分散式服務資料一致性-mysql篇分散式MySql
- 什麼是抖音本地生活服務?本地生活服務有什麼優勢?
- Docker實現服務發現Docker
- etcd實現服務發現
- SaaS服務平臺為中小企業實現企業管理
- 資料服務在新媒體業務體系中的實踐
- 如何管理服務業務中的專案收入?
- 到底什麼是微服務?其實就是DDD領域服務微服務