之前聊了《數據庫雙主一致性問題解決方案》，今天聊聊數據庫主庫與從庫的一致性問題。

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

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

如上圖：

• 一個主庫提供寫服務；
• 多個從庫提供讀服務，提升讀性能；
• 主從之間同步數據；

問：為什么會出現不一致？

主從同步有時延，時延期間讀從庫，主從同步未完成，可能讀到臟數據。

圖片

任何數據冗余，必將引發一致性問題。

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

常見的方法有4種。

方案一：忽略。

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

如果業務能夠接受，別把系統架構搞得太復雜。

方案二：半同步復制

不一致是因為主從同步有一個時間差，是否能做到，等主從同步完成之后，主庫上的寫請求再返回呢？

這就是大家常說的半同步復制semi-sync。

• 1. 主庫先執行寫操作；
• 2. 等主從同步完成，寫請求才返回；
• 3. 讀從庫，就能讀到最新的數據；

這個方案的優點是，利用數據庫原生功能，比較簡單。不足是，主庫的寫請求時延會增加，吞吐量會降低。

方案三：強制讀主。

如上圖：

• 使用一個高可用主庫提供數據庫服務；
• 讀和寫都落到主庫上；
• 采用緩存來提升系統讀性能；

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

方案四：選擇性讀主。

強制讀主過于粗暴，畢竟只有少量寫請求，很短時間，可能讀取到臟數據。

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

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

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

• 寫主庫；
• 將哪個庫，哪個表，哪個主鍵三個信息拼裝一個key設置到cache里，這條記錄的超時時間，設置為“主從同步時延”；

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

如上圖，當讀請求發生時，這是要讀哪個庫，哪個表，哪個主鍵的數據呢，也將這三個信息拼裝一個key，到cache里去查詢，如果：

• cache里有這個key，說明1s內剛發生過寫請求，數據庫主從同步可能還沒有完成，此時就應該去主庫查詢；
• cache里沒有這個key，說明最近沒有發生過寫請求，此時就可以去從庫查詢；

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

總結

數據庫主從不一致，四種常見優化方案：

• 忽略：業務可以接受，系統不優化；
• 半同步復制：復用原生能力，犧牲部分性能；
• 強制讀主：高可用主庫，用緩存提高讀性能；
• 選擇性讀主：在cache里記錄哪些記錄發生過寫請求，來路由讀主還是讀從；

知其然，知其所以然。

思路比結論更重要。