Hello,大家好！我是樓下小黑哥，我又來了~ 今天分享一下剛入職公司第一次釋出專案遇到的一個問題，一個數據庫讀寫分離的坑。 ## 前言 事情是這樣的，剛入職的時候接到了這樣的一個業務需求： 每個支付通道支付失敗的時候都會返回特定的錯誤碼，業務內部需要將通道特定的錯誤碼轉義成內部的錯誤碼，這樣對外就可以統一返回我們自己的錯誤碼。 這個需求其實不難，當時設計的系統架構如下：  新增規則的流程簡單分為三步： 1. 業務人員通過管理後臺新增對映規則 2. 資料庫新增、修改這條對映規則 3. 刪除快取 這裡之所以增加快取，是因為這個場景每次支付都需要使用，使用快取可以避免每次都去資料庫讀取，增加讀取速度。 後續支付請求業務流程如下：  當快取內對映規則不存在的時候，將會查詢資料庫，然後載入到快取中。如果快取內對映規則已存在，將會直接使用快取內對映規則。 這個業務流程其實比較簡單，當時在測試環境測試也沒問題，後續釋出線上環境的卻碰到奇怪的問題。 **新增規則之後，一段時間內，對映規則並沒有生效。檢視日誌發現，查詢資料庫的時候，沒有資料。** *這就很奇怪了，日誌顯示新增是成功，但是查詢卻沒有資料。但是過了一段時間，再次查詢卻又有了資料。* 走查了下程式碼，發現並沒有什麼問題，第二天上班的時候請教了一下同事，才知道問題的原因： 原來線上的資料庫採用主從架構，資料讀寫分離，資料查詢走的是從庫。資料寫入都是直接操作主庫，後續再同步到從庫。 **由於資料庫同步存在延時，這就導致資料同步的這段時間，主從資料將會不一致，從庫無法查詢到最新的資料。** 如果你之前的資料庫系統架構是單庫或者主備結構，當你第一次轉到資料讀寫分離架構，這個坑大概率也會踩到。  ## 資料庫系統架構發展 下面我們首先了解一下資料庫系統架構，最後再來看下如何解決主從同步延時的導致資料不一致。 ### 主備架構 業務發展的前期，資料訪問量小，這時我們可以直接採用單庫的架構。  不過我們一般不使用的上面的架構，因為存在單點的問題。若資料庫出現故障，這段期間業務將會不可用。我們除了等待重啟，其他沒什麼解決辦法。 所以我們會增加一個備庫，實時同步主庫的資料。  一旦「主庫」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。 這種架構，部署維護簡單，業務開發也無需任何改造。 不過缺點也很明顯，備庫只有在主庫有問題的時候才會被啟用，存在一定的資源浪費的情況。 ### 主從架構 隨著業務發展，請求量不斷變大，資料量也不斷變大，業務變得更加複雜，很快資料將會到達瓶頸。 由於大多數業務都是讀多寫少，所以資料庫讀的最容易成為系統瓶頸。 這時候我們可以提高讀的效能，這時我們的可以採用的方案，增加從例項，主從同步，資料讀寫分離。  可以看到這個架構與主備沒什麼區別，主要區別在於主從架構下，從庫與主庫一樣，時刻需要幹活，主庫提供寫服務，從庫只提供讀服務。 如果後續讀的壓力還是太大，我們還可以增加從庫的數量，水平擴充讀的能力。 雖然主從架構幫我們解決讀的瓶頸，但是由於主從之間需要資料同步，這天然就存在一定延時。 在這延時視窗期內，從庫的讀只能讀到一箇舊資料，這也是上面案例問題的真正的原因。  接下來我們來看下有什麼辦法可以優化這種情況。 ## 主從延時解決辦法 ### 忍受大法 第一種解決辦法，很簡單，無他，不管他，沒有讀到也沒事。這時業務不需要任何改造，你好，我好，她也好~  如果業務對於資料一致性要求不高，我們就可以採用這種方案。 ### 資料同步寫方案 主從資料同步方案，一般都是採用的非同步方式同步給備庫。 我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能返回。 ​  1. 業務系統發起寫操作，資料寫主庫 2. 寫請求需要等待主從同步完成才能返回 3. 資料讀從庫，主從同步完成就能讀到最新資料 這種方案，我們只需要修改資料庫之間同步配置即可，業務層無需修改，相對簡單。 **不過，由於主庫寫需要等待主從完成，寫請求的時延將會增加，吞吐量將會降低。** 這一點對於現在線上業務，可能無法接受。 ### 選擇性強制讀主 對於需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣**讀寫都在主庫**，就沒有不一致的情況。  這種方案業務層需要改造一下，將其強制性讀主，相對改造難度較低。 不過這種方案相對於浪費了另一個數據庫，增加主庫的壓力。 ### 中介軟體選擇路由法 這種方案需要使用一箇中間件，所有資料庫操作都先發到中介軟體，由中介軟體再分發到相應的資料庫。  這時流程如下： 1. 寫請求，中介軟體將會發到主庫，同時記錄一下此時寫請求的 key（*操作表加主鍵等*） 2. 讀請求，如果此時 key 存在，將會路由到主庫 3. 一定時間後（*經驗值*），中介軟體認為主從同步完成，刪除這個 key，後續讀將會讀從庫 這種方案，可以保持資料讀寫的一致。 但是系統架構增加了一箇中間件，整體複雜度變高，業務開發也變得複雜，學習成本也比較高。 ### 快取路由大法 這種方案與中介軟體的方案流程比較類似，不過改造成本相對較低，不需要增加任何中介軟體。  這時流程如下: 1. 寫請求發往主庫，同時快取記錄操作的 key，快取的失效時間設定為主從的延時 2. 讀請求首先判斷快取是否存在 - 若存在，代表剛發生過寫操作，讀請求操作主庫 - 若不存在，代表近期沒發生寫操作，讀請求操作從庫 這種方案相對中介軟體的方案成本較低，但是呢我們此時又引入一個快取元件，所有讀寫之間就又多了一步快取操作。 ## 總結 我們引入主從架構，資料讀寫分離，目的是為了解決業務快速發展,請求量變大，併發量變大，從而引發的資料庫的讀瓶頸。 不過當引入新一個架構解決問題時，勢必會帶來另外一個問題，資料庫讀寫分離之後，主從延遲從而導致資料不一致的情況。， 為了解決主從延遲，資料不一致的情況，我們可以採用以下這幾種方案： 1. 忍受大法 2. 資料庫同步寫方案 3. 選擇性強制讀主 4. 中介軟體選擇路由法 5. 快取路由大法 上面的方案都有各自的優點，當然也有相應的缺點，我們需要根據自己的業務情況，選擇相應的解決方案。 好了，今天的文章就到此。 我是樓下小黑哥，下週見~ ## 參考連結 1. [資料庫主從不一致，怎麼解？](https://mp.weixin.qq.com/s/5JYtta9aMGcic7o_ejna-A) > 歡迎關注我的公眾號：小黑十一點半，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：[studyidea.cn](https://studyi