DB主從一致性架構優化4種方法

原創 2016-05-18 58沈劍 架構師之路

需求緣起

大部分互聯網的業務都是「讀多寫少」的場景，數據庫層面，讀性能每每成爲瓶頸。以下圖：業界一般採用「一主多從，讀寫分離，冗餘多個讀庫」的數據庫架構來提高數據庫的讀性能。

這種架構的一個潛在缺點是，業務方有可能讀取到並非最新的舊數據：

（1）系統先對DB-master進行了一個寫操做，寫主庫

（2）很短的時間內併發進行了一個讀操做，讀從庫，此時主從同步沒有完成，故讀取到了一箇舊數據

（3）主從同步完成

 

有沒有辦法解決或者緩解這類「因爲主從延時致使讀取到舊數據」的問題呢，這是本文要集中討論的問題。

 

方案一（半同步複製）

不一致是由於寫完成後，主從同步有一個時間差，假設是500ms，這個時間差有讀請求落到從庫上產生的。有沒有辦法作到，等主從同步完成以後，主庫上的寫請求再返回呢？答案是確定的，就是你們常說的「半同步複製」semi-sync：

（1）系統先對DB-master進行了一個寫操做，寫主庫

（2）等主從同步完成，寫主庫的請求才返回

（3）讀從庫，讀到最新的數據（若是讀請求先完成，寫請求後完成，讀取到的是「當時」最新的數據）

方案優勢：利用數據庫原生功能，比較簡單

方案缺點：主庫的寫請求時延會增加，吞吐量會下降

 

方案二（強制讀主庫）

若是不使用「增長從庫」的方式來增長提高系統的讀性能，徹底能夠讀寫都落到主庫，這樣就不會出現不一致了：

方案優勢：「一致性」上不須要進行系統改造

方案缺點：只能經過cache來提高系統的讀性能，這裏要進行系統改造

 

方案三（數據庫中間件）

若是有了數據庫中間件，全部的數據庫請求都走中間件，這個主從不一致的問題能夠這麼解決：

（1）全部的讀寫都走數據庫中間件，一般狀況下，寫請求路由到主庫，讀請求路由到從庫

（2）記錄全部路由到寫庫的key，在經驗主從同步時間窗口內（假設是500ms），若是有讀請求訪問中間件，此時有可能從庫仍是舊數據，就把這個key上的讀請求路由到主庫

（3）經驗主從同步時間過完後，對應key的讀請求繼續路由到從庫

方案優勢：能保證絕對一致

方案缺點：數據庫中間件的成本比較高

 

方案四（緩存記錄寫key法）

既然數據庫中間件的成本比較高，有沒有更低成本的方案來記錄某一個庫的某一個key上發生了寫請求呢？很容易想到使用緩存，當寫請求發生的時候：

（1）將某個庫上的某個key要發生寫操做，記錄在cache裏，並設置「經驗主從同步時間」的cache超時時間，例如500ms

（2）修改數據庫

 

而讀請求發生的時候：

（1）先到cache裏查看，對應庫的對應key有沒有相關數據

（2）若是cache hit，有相關數據，說明這個key上剛發生過寫操做，此時須要將請求路由到主庫讀最新的數據

（3）若是cache miss，說明這個key上近期沒有發生過寫操做，此時將請求路由到從庫，繼續讀寫分離

方案優勢：相對數據庫中間件，成本較低

方案缺點：爲了保證「一致性」，引入了一個cache組件，而且讀寫數據庫時都多了一步cache操做

 

總結

爲了解決主從數據庫讀取舊數據的問題，經常使用的方案有四種：

（1）半同步複製

（2）強制讀主

（3）數據庫中間件

（4）緩存記錄寫key

 

前3個方案在今年數據庫大會（DTCC2016）上share過，相關的材料在網上能下載到。第4個方案是大會現場有其餘同窗share的一個好方法，感謝這位同窗。

==【全文完，但願大夥有收穫】==

回【設置】線程數究竟設多少合理

回【秒殺】秒殺系統架構優化思路

回【消息】58到家通用實時消息平臺架構細節

回【id】細聊分佈式ID生成方法

回【監控】創業公司快速搭創建體化監控

回【百度】百度咋作長文本去重

 

【小遊戲：回大於10的整數，隨機返回好文，猜猜怎麼實現的】

 

歡迎討論，有問必答。

如有收穫，幫忙轉發。