數據庫讀寫分離這個坑，你應該踩過吧？

Hello,你們好！我是樓下小黑哥，我又來了~

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

前言

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

每一個支付通道支付失敗的時候都會返回特定的錯誤碼，業務內部須要將通道特定的錯誤碼轉義成內部的錯誤碼，這樣對外就能夠統一返回咱們本身的錯誤碼。

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

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

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

這裏之因此增長緩存，是由於這個場景每次支付都須要使用，使用緩存能夠避免每次都去數據庫讀取，增長讀取速度。

後續支付請求業務流程以下：

當緩存內映射規則不存在的時候，將會查詢數據庫，而後加載到緩存中。若是緩存內映射規則已存在，將會直接使用緩存內映射規則。

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

新增規則以後，一段時間內，映射規則並無生效。查看日誌發現，查詢數據庫的時候，沒有數據。

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

走查了下代碼，發現並無什麼問題，次日上班的時候請教了一下同事，才知道問題的緣由：

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

因爲數據庫同步存在延時，這就致使數據同步的這段時間，主從數據將會不一致，從庫沒法查詢到最新的數據。

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

數據庫系統架構發展

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

主備架構

業務發展的前期，數據訪問量小，這時咱們能夠直接採用單庫的架構。

不過咱們通常不使用的上面的架構，由於存在單點的問題。若數據庫出現故障，這段期間業務將會不可用。咱們除了等待重啓，其餘沒什麼解決辦法。

因此咱們會增長一個備庫，實時同步主庫的數據。

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

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

不過缺點也很明顯，備庫只有在主庫有問題的時候纔會被啓用，存在必定的資源浪費的狀況。

主從架構

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

因爲大多數業務都是讀多寫少，因此數據庫讀的最容易成爲系統瓶頸。

這時候咱們能夠提升讀的性能，這時咱們的能夠採用的方案，增長從實例，主從同步，數據讀寫分離。

能夠看到這個架構與主備沒什麼區別，主要區別在於主從架構下，從庫與主庫同樣，時刻須要幹活，主庫提供寫服務，從庫只提供讀服務。

若是後續讀的壓力仍是太大，咱們還能夠增長從庫的數量，水平擴充讀的能力。

雖然主從架構幫咱們解決讀的瓶頸，可是因爲主從之間須要數據同步，這自然就存在必定延時。

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

接下來咱們來看下有什麼辦法能夠優化這種狀況。

主從延時解決辦法

忍受大法

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

若是業務對於數據一致性要求不高，咱們就能夠採用這種方案。

數據同步寫方案

主從數據同步方案，通常都是採用的異步方式同步給備庫。

咱們能夠將其修改成同步方案，主從同步完成，主庫上的寫才能返回。

​

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

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

不過，因爲主庫寫須要等待主從完成，寫請求的時延將會增長，吞吐量將會下降。

這一點對於如今在線業務，可能沒法接受。

選擇性強制讀主

對於須要強一致的場景，咱們能夠將其的讀請求都操做主庫，這樣讀寫都在主庫，就沒有不一致的狀況。

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

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

中間件選擇路由法

這種方案須要使用一箇中間件，全部數據庫操做都先發到中間件，由中間件再分發到相應的數據庫。

這時流程以下：

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

這種方案，能夠保持數據讀寫的一致。

可是系統架構增長了一箇中間件，總體複雜度變高，業務開發也變得複雜，學習成本也比較高。

緩存路由大法

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

這時流程以下:

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

這種方案相對中間件的方案成本較低，可是呢咱們此時又引入一個緩存組件，全部讀寫之間就又多了一步緩存操做。

總結

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

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

爲了解決主從延遲，數據不一致的狀況，咱們能夠採用如下這幾種方案：

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

上面的方案都有各自的優勢，固然也有相應的缺點，咱們須要根據本身的業務狀況，選擇相應的解決方案。

好了，今天的文章就到此。

我是樓下小黑哥，下週見~

參考連接

1. 數據庫主從不一致，怎麼解？

歡迎關注個人公衆號：小黑十一點半，得到平常乾貨推送。若是您對個人專題內容感興趣，也能夠關注個人博客：studyidea.cn