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

資料庫分散式系統閘道器 · 發表 2019-05-09 16:23:57

摘要：轉載本文需註明出處：微信公眾號EAWorld，違者必究。針對分散式架構下的資料一致性，大家也許會問這樣的問題：跨系統間分散式事務如何解決？系統內多個服務的分散式事務如何解決？一個服務內多個數據源/資料庫的分散式事務如何解決？……這些問題大家是很容易理解的，但是由於術語不準確，所...

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

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

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

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

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

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

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

1、系統間的資料一致性

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

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

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

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

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