需求緣起
大部分網際網路的業務都是「讀多寫少」的場景，資料庫層面，讀效能往往成為瓶頸。如下圖：業界通常採用「一主多從，讀寫分離，冗餘多個讀庫」的資料庫架構來提公升資料庫的讀效能。
這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料：
（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
DB主從一致性架構優化4種方法
需求緣起 大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。系統先對 db master 進行了乙個寫操作，寫主庫 2 很短的時間內併發進行了乙個讀操作，讀從庫，此時主從同步沒有完成...
DB主從一致性架構優化4種方法
大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2 很短的時...
DB主從一致性架構優化4種方法
大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2 很短的時...