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