redis 數據庫主從不一致問題解決方案

 在聊數據庫與緩存一致性問題以前，先聊聊數據庫主庫與從庫的一致性問題。

 

問：常見的數據庫集羣架構如何？

答：一主多從，主從同步，讀寫分離。

如上圖：

（1）一個主庫提供寫服務

（2）多個從庫提供讀服務，能夠增長從庫提高讀性能

（3）主從之間同步數據

畫外音：任何方案不要忘了本心，加從庫的本心，是提高讀性能。

 

問：爲何會出現不一致？

答：主從同步有時延，這個時延期間讀從庫，可能讀到不一致的數據。

如上圖：

（1）服務發起了一個寫請求

（2）服務又發起了一個讀請求，此時同步未完成，讀到一個不一致的髒數據

（3）數據庫主從同步最後才完成

畫外音：任何數據冗餘，必將引起一致性問題。

 

問：如何避免這種主從延時致使的不一致？

答：常見的方法有這麼幾種。

 

方案一：忽略

任何脫離業務的架構設計都是耍流氓，絕大部分業務，例如：百度搜索，淘寶訂單，QQ消息，58帖子都容許短期不一致。

畫外音：若是業務能接受，最推崇此法。

 

若是業務可以接受，別把系統架構搞得太複雜。

 

方案二：強制讀主

如上圖：

（1）使用一個高可用主庫提供數據庫服務

（2）讀和寫都落到主庫上

（3）採用緩存來提高系統讀性能

這是很常見的微服務架構，能夠避免數據庫主從一致性問題。

 

方案三：選擇性讀主

強制讀主過於粗暴，畢竟只有少許寫請求，很短期，可能讀取到髒數據。

 

有沒有可能實現，只有這一段時間，可能讀到從庫髒數據的讀請求讀主，平時讀從呢？

 

能夠利用一個緩存記錄必須讀主的數據。

如上圖，當寫請求發生時：

（1）寫主庫

（2）將哪一個庫，哪一個表，哪一個主鍵三個信息拼裝一個key設置到cache裏，這條記錄的超時時間，設置爲「主從同步時延」

畫外音：key的格式爲「db:table:PK」，假設主從延時爲1s，這個key的cache超時時間也爲1s。

 

如上圖，當讀請求發生時：

這是要讀哪一個庫，哪一個表，哪一個主鍵的數據呢，也將這三個信息拼裝一個key，到cache裏去查詢，若是，

（1）cache裏有這個key，說明1s內剛發生過寫請求，數據庫主從同步可能尚未完成，此時就應該去主庫查詢

（2）cache裏沒有這個key，說明最近沒有發生過寫請求，此時就能夠去從庫查詢

以此，保證讀到的必定不是不一致的髒數據。

 

總結

數據庫主庫和從庫不一致，常見有這麼幾種優化方案：

（1）業務能夠接受，系統不優化

（2）強制讀主，高可用主庫，用緩存提升讀性能

（3）在cache裏記錄哪些記錄發生過寫請求，來路由讀主仍是讀從