Hello，大家好！我是樓下小黑哥，我又來了~本文分享一下以前入職現在公司第一次發布項目遇到的一個問題，一個數據庫讀寫分離的坑。

前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[359763]]

一、數據庫系統架構發展

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

1、主備架構

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

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

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

主備架構

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

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

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

2、主從架構

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

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

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

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

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

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

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

[[359767]]

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

二、主從延時解決辦法

1、忍受大法

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

[[359768]]

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

2、數據同步寫方案

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

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

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

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

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

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

3、選擇性強制讀主

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

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

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

4、中間件選擇路由法

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

這時流程如下：

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

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

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

5、緩存路由大法

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

這時流程如下:

•  寫請求發往主庫，同時緩存記錄操作的 key，緩存的失效時間設置為主從的延時；
•  讀請求首先判斷緩存是否存在：

          若存在，代表剛發生過寫操作，讀請求操作主庫；

          若不存在，代表近期沒發生寫操作，讀請求操作從庫。

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

三、總結

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

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

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

•  忍受大法；
•  數據庫同步寫方案；
•  選擇性強制讀主；
•  中間件選擇路由法；
•  緩存路由大法。

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