今天分享一下以前入職現在公司第一次發布項目遇到的一個問題，一個數據庫讀寫分離的坑。

前言

事情是這樣的，剛入職的時候接到了這樣的一個業務需求：

每個支付通道支付失敗的時候都會返回特定的錯誤碼，業務內部需要將通道特定的錯誤碼轉義成內部的錯誤碼，這樣對外就可以統一返回我們自己的錯誤碼。

這個需求其實不難，當時設計的系統架構如下：

新增規則的流程簡單分為三步：

1.  業務人員通過管理后臺新增映射規則
2.  數據庫新增、修改這條映射規則
3.  刪除緩存

這里之所以增加緩存，是因為這個場景每次支付都需要使用，使用緩存可以避免每次都去數據庫讀取，增加讀取速度。

后續支付請求業務流程如下：

數據庫讀寫分離-用戶操作

當緩存內映射規則不存在的時候，將會查詢數據庫，然后加載到緩存中。如果緩存內映射規則已存在，將會直接使用緩存內映射規則。

這個業務流程其實比較簡單，當時在測試環境測試也沒問題，后續發布線上環境的卻碰到奇怪的問題。

「新增規則之后，一段時間內，映射規則并沒有生效。查看日志發現，查詢數據庫的時候，沒有數據。」

這就很奇怪了，日志顯示新增是成功，但是查詢卻沒有數據。但是過了一段時間，再次查詢卻又有了數據。

走查了下代碼，發現并沒有什么問題，第二天上班的時候請教了一下同事，才知道問題的原因：

原來線上的數據庫采用主從架構，數據讀寫分離，數據查詢走的是從庫。數據寫入都是直接操作主庫，后續再同步到從庫。

「由于數據庫同步存在延時，這就導致數據同步的這段時間，主從數據將會不一致，從庫無法查詢到最新的數據。」

如果你之前的數據庫系統架構是單庫或者主備結構，當你第一次轉到數據讀寫分離架構，這個坑大概率也會踩到。

[[357035]]

數據庫系統架構發展

下面我們首先了解一下數據庫系統架構，最后再來看下如何解決主從同步延時的導致數據不一致。

主備架構

業務發展的前期，數據訪問量小，這時我們可以直接采用單庫的架構。

不過我們一般不使用的上面的架構，因為存在單點的問題。若數據庫出現故障，這段期間業務將會不可用。我們除了等待重啟，其他沒什么解決辦法。

所以我們會增加一個備庫，實時同步主庫的數據。

主備架構

一旦「主庫」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。

這種架構，部署維護簡單，業務開發也無需任何改造。

不過缺點也很明顯，備庫只有在主庫有問題的時候才會被啟用，存在一定的資源浪費的情況。

主從架構

隨著業務發展，請求量不斷變大，數據量也不斷變大，業務變得更加復雜，很快數據將會到達瓶頸。

由于大多數業務都是讀多寫少，所以數據庫讀的最容易成為系統瓶頸。

這時候我們可以提高讀的性能，這時我們的可以采用的方案，增加從實例，主從同步，數據讀寫分離。

可以看到這個架構與主備沒什么區別，主要區別在于主從架構下，從庫與主庫一樣，時刻需要干活，主庫提供寫服務，從庫只提供讀服務。

如果后續讀的壓力還是太大，我們還可以增加從庫的數量，水平擴充讀的能力。

雖然主從架構幫我們解決讀的瓶頸，但是由于主從之間需要數據同步，這天然就存在一定延時。

在這延時窗口期內，從庫的讀只能讀到一個舊數據，這也是上面案例問題的真正的原因。

[[357039]]

接下來我們來看下有什么辦法可以優化這種情況。

主從延時解決辦法

忍受大法

第一種解決辦法，很簡單，無他，不管他，沒有讀到也沒事。這時業務不需要任何改造，你好，我好，她也好~

[[357040]]

如果業務對于數據一致性要求不高，我們就可以采用這種方案。

數據同步寫方案

主從數據同步方案，一般都是采用的異步方式同步給備庫。

我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能返回。

 

 

1.  業務系統發起寫操作，數據寫主庫
2.  寫請求需要等待主從同步完成才能返回
3.  數據讀從庫，主從同步完成就能讀到最新數據

這種方案，我們只需要修改數據庫之間同步配置即可，業務層無需修改，相對簡單。

「不過，由于主庫寫需要等待主從完成，寫請求的時延將會增加，吞吐量將會降低。」

這一點對于現在在線業務，可能無法接受。

選擇性強制讀主

對于需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣「讀寫都在主庫」，就沒有不一致的情況。

這種方案業務層需要改造一下，將其強制性讀主，相對改造難度較低。

不過這種方案相對于浪費了另一個數據庫，增加主庫的壓力。

中間件選擇路由法

這種方案需要使用一個中間件，所有數據庫操作都先發到中間件，由中間件再分發到相應的數據庫。

這時流程如下：

1.  寫請求，中間件將會發到主庫，同時記錄一下此時寫請求的 key（操作表加主鍵等）
2.   讀請求，如果此時 key 存在，將會路由到主庫
3.  一定時間后（經驗值），中間件認為主從同步完成，刪除這個 key，后續讀將會讀從庫

這種方案，可以保持數據讀寫的一致。

但是系統架構增加了一個中間件，整體復雜度變高，業務開發也變得復雜，學習成本也比較高。

緩存路由大法

這種方案與中間件的方案流程比較類似，不過改造成本相對較低，不需要增加任何中間件。

這時流程如下:

1.  寫請求發往主庫，同時緩存記錄操作的 key，緩存的失效時間設置為主從的延時
2.  讀請求首先判斷緩存是否存在
   
   1.   若存在，代表剛發生過寫操作，讀請求操作主庫
   2.   若不存在，代表近期沒發生寫操作，讀請求操作從庫

這種方案相對中間件的方案成本較低，但是呢我們此時又引入一個緩存組件，所有讀寫之間就又多了一步緩存操作。

總結

我們引入主從架構，數據讀寫分離，目的是為了解決業務快速發展,請求量變大，并發量變大，從而引發的數據庫的讀瓶頸。

不過當引入新一個架構解決問題時，勢必會帶來另外一個問題，數據庫讀寫分離之后，主從延遲從而導致數據不一致的情況。，

為了解決主從延遲，數據不一致的情況，我們可以采用以下這幾種方案：

1.  忍受大法
2.  數據庫同步寫方案
3.  選擇性強制讀主
4.  中間件選擇路由法
5.  緩存路由大法

上面的方案都有各自的優點，當然也有相應的缺點，我們需要根據自己的業務情況，選擇相應的解決方案。