需求緣起
大部分網際網路的業務都是「讀多寫少」的場景，資料庫層面，讀效能往往成為瓶頸。如下圖：業界通常採用「一主多從，讀寫分離，冗餘多個讀庫」的資料庫架構來提公升資料庫的讀效能。
）系統先對
db-master
進行了乙個寫操作，寫主庫
（2）很短的時間內併發進行了乙個讀操作，讀從庫，此時主從同步沒有完成，故讀取到了乙個舊資料
（3）主從同步完成
有沒有辦法解決或者緩解這類「由於主從延時導致讀取到舊資料」的問題呢，這是本文要集中討論的問題。
方案一（半同步複製）
不一致是因為寫完成後，主從同步有乙個時間差，假設是500ms，這個時間差有讀請求落到從庫上產生的
。有沒有辦法做到，等主從同步完成之後，主庫上的寫請求再返回呢？答案是肯定的，就是大家常說的「半同步複製」semi-sync：
）系統先對
db-master
進行了乙個寫操作，寫主庫
（2）等主從同步完成，寫主庫的請求才返回
（3）讀從庫，讀到最新的資料（如果讀請求先完成，寫請求後完成，讀取到的是「當時」最新的資料）
方案優點
：利用資料庫原生功能，比較簡單
方案缺點
：主庫的寫請求時延會增長，吞吐量會降低
方案二（強制讀主庫）
如果不使用「增加從庫」的方式來增加提公升系統的讀效能，完全可以讀寫都落到主庫，這樣就不會出現不一致了：
方案優點
：「一致性」上不需要進行系統改造
方案缺點
：只能通過cache來提公升系統的讀效能，這裡要進行系統改造
方案三（資料庫中介軟體）
如果有了資料庫中介軟體，所有的資料庫請求都走中介軟體，這個主從不一致的問題可以這麼解決：
）所有的讀寫都走資料庫中介軟體，通常情況下，寫請求路由到主庫，讀請求路由到從庫
（2）記錄所有路由到寫庫的key
，在經驗主從同步時間視窗內（假設是500ms），如果有讀請求訪問中介軟體，此時有可能從庫還是舊資料，就把這個key上的讀請求路由到主庫
（3）經驗主從同步時間過完後，對應key的讀請求繼續路由到從庫
方案優點
：能保證絕對一致
方案缺點
：資料庫中介軟體的成本比較高
方案四（快取記錄寫key法）
既然資料庫中介軟體的成本比較高，有沒有更低成本的方案來記錄某乙個庫的某乙個key上發生了寫請求呢？很容易想到使用快取，當寫請求發生的時候：
）將某個庫上的某個
key要發生寫操作，記錄在
cache
裡，並設定「經驗主從同步時間」的cache超時時間，例如
500ms
（2）修改資料庫
而讀請求發生的時候：
）先到cache
裡檢視，對應庫的對應
key有沒有相關資料
（2）如果cache hit
，有相關資料，說明這個key上剛發生過寫操作，此時需要將請求路由到主庫讀最新的資料
（3）如果cache miss
，說明這個key上近期沒有發生過寫操作，此時將請求路由到從庫，繼續讀寫分離
方案優點
：相對資料庫中介軟體，成本較低
方案缺點
：為了保證「一致性」，引入了乙個cache元件，並且讀寫資料庫時都多了一步cache操作
總結為了解決主從資料庫讀取舊資料的問題，常用的方案有四種：
（1）半同步複製
（2）強制讀主
（3）資料庫中介軟體
（4）快取記錄寫key
DB主從一致性架構優化4種方法
需求緣起 大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2...
DB主從一致性架構優化4種方法
大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2 很短的時...
DB主從一致性架構優化4種方法
大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2 很短的時...