分散式架構中資料一致性常見的幾個問題

EAWorld發表於2019-05-07

分散式架構中資料一致性常見的幾個問題

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

針對分散式架構下的資料一致性,大家也許會問這樣的問題:跨系統間分散式事務如何解決?系統內多個服務的分散式事務如何解決?一個服務內多個資料來源/資料庫的分散式事務如何解決?……這些問題大家是很容易理解的,但是由於術語不準確,所以解釋起來會有二義性,所以先要統一語言或者術語,也就是統一概念:


分散式架構中資料一致性常見的幾個問題


域是一個虛擬的分類,幾個系統屬於某一個域,例如網上銀行和手機銀行都屬於電子渠道領域;

傳統的單體應用,指的就是系統,在微服務架構下,單體應用採用前後端分離模式,前端一般使用 Nginx,Ngnix 程式間採用主備模式,系統的後端可以分為多個應用,每個應用有一組對等的應用程式(也稱為應用例項)提供服務,每個應用對應一個資料庫,實際上在分庫的情況下,有可能一個應用對應多個資料庫。複雜一點的是閘道器,閘道器由一組對等的閘道器例項組成,如果多個系統共享一個閘道器,閘道器和系統就是1對多的關係,也可以一個系統獨享一個閘道器,就是一對一情況,下圖是一個概念的示例,使用的是系統獨享閘道器模式。

分散式架構中資料一致性常見的幾個問題


這裡,我們看看經常問的一些問題:跨系統間分散式事務、系統內多個服務的分散式事務、一個服務內多個資料來源/資料庫的分散式事務,這些問題完全是從技術的角度做歸納,用上述概念應該改為:系統間的資料一致性、系統內應用間的資料一致性、應用內部對應多資料庫的資料一致性,另外可以增加一個資料庫對應多個應用的資料一致性(技術上存在可能,但從上述概念上看應該是在架構上避免的)。

這四個情況如何處理呢?需要我們總結歸納,我在做總結歸納的時候,往往希望首先確定原則,這裡的原則是從業務的角度進行分析,而不是考慮技術的可能性,因為技術的可能性無窮無盡,是一個無限組合,理論上任何情況都能發生,考慮所有情況就是胡扯了,必須根據業務的特徵進行歸納。這裡,我不叫分散式事務而是資料一致性就是這個道理,從業務角度目標是解決分散式情況下的資料一致性,而不是技術角度看的分散式事務。

有了這個原則,就可以分別分析這四種情況了:

1、系統間的資料一致性

需要服務實現 TCC或者業務補償模式,由框架(業務協調器)自動呼叫,減少人工參與,或者實現冪等服務,反覆投遞。這兩種方式都沒法做到資料的 100% 一致,在失敗的時候都需要有重試的機制,例如補償失敗要重試(這就是框架的好處),多次重試還是失敗,記錄失敗歷史,業務上人工處理。不要害怕人工處理,只要減少人工處理的機會就好了,在工行時就是提出人工干預比例降低若干個百分點作為目標。

2、系統內應用間的資料一致性

這個可以使用華為 SAGA 的模式,也就是建立一個共享的事務協調器模式(雖然我對這個共享方式不喜歡,不是分散式嗎,為啥還搞出一堆集中式的東西,既然如此,為啥應用間呼叫不能走閘道器,要直連,說共享不好,到這裡就是共享好了),好了,括號裡是吐槽,簡單的方式是用共享的事務協調器模式,記錄服務呼叫的事件,在合適的時機呼叫TCC和補償服務。

3、應用內部對應多資料庫的資料一致性,是個反模式,不要做通用方案

一般來說,一個應用對應一個資料庫,不允許一個應用對應多個資料庫,多個資料庫的情況應該分成多個應用,透過服務呼叫方式解決,這是一個基本原則,否則就是一個反模式設計。但是,就是有很多人較真,一定問有這個情況你怎麼解決,我的回答是架構設計解決這個問題,在技術上不支援這種方式,讓設計者必須在架構解決,而不是利用技術手段解決不合理的架構設計,否則後患無窮這一點還是需要勇氣和堅持的)。空口無憑,例項為證,一般我會舉搶紅包的例子。大家知道,搶紅包的併發非常高,又有資料一致性的要求,無論哪個網際網路公司,都是根據紅包 ID,把資料路由到一個資料庫中,用資料庫事務保證資料一致性,在銀行網際網路賬務系統(2類 3類戶)的情況,也是把同一賬務的資料路由到不同的資料庫中(見下圖)。還會提到一種情況,在分庫分表的時候,如果恰好資料分到了不同庫中,恰好要做一個批次的調整,恰好在一個事務中,如何解決。我認為這種情況的發生,恰恰說明設計有問題,分庫的原則也是按業務拆分,不是用技術手段隨機分解,既然按業務拆分,批次處理的時候就應該不是一個業務上的事務,在技術上不提供這樣的實現,才可以在架構設計考慮問題。不排除在某個系統中可以做一些框架,解決上述問題,但是,這一定不是個通用的方案。

分散式架構中資料一致性常見的幾個問題


根據上圖,我們的概念模型是由調整的,要多一個應用分割槽的情況:

分散式架構中資料一致性常見的幾個問題


分散式架構中資料一致性常見的幾個問題


4、一個資料庫對應多個應用的資料一致性

這種情況經常也是一個反模式,既然是共享一個資料庫,把應用放在一起就好了。如果真的有需要(例如一個模組部署過於頻繁,單獨拆出來做一個應用),那也應該和多應用多資料庫一樣處理。

以上,即是我分析的分散式架構下幾種不同情況的資料一致性控制方式。


分散式架構中資料一致性常見的幾個問題

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

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

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

相關文章