原文：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959442&idx=1&sn=feb8ff75385d8031386e120ef3535329&mpshare=1&scene=1&srcid=0414Sfz5073uJ0LtONVjo8lR&key=58a327fab9b03b4d2d299413f7071fd84a44bcdb554512e8a13284f7639f4448181da21c9f104e837afb44e7549b5d0c73bdf2e31a78927d66ae345a4f3360eb3ea7b566808edfb74d8ecf70eccc5c3f&ascene=1&uin=MTc0NDg2MzA2MQ%3D%3D&devicetype=Windows+10&version=62060739&lang=zh_CN&pass_ticket=tW64Z%2F34hwZyRqWaBBwgDqdNjLnpWPiYL7A0nhfurpDF7xeaYQgdG22dV0k1VGKJ
作者： 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逾時時間，例如500m
（2）修改資料庫
而讀請求發生的時候：
（1）先到cache裡檢視，對應庫的對應key有沒有相關資料
（2）如果
cache hit
，有相關資料，說明這個key上剛發生過寫操作，此時需要将
請求路由到主庫讀
最新的資料
（3）如果
cache miss
，說明這個key上近期沒有發生過寫操作，此時将
請求路由到從庫
，繼續讀寫分離
方案優點： 相對資料庫中間件，
成本較低
方案缺點： 為了保證“一緻性”，
引入了一個cache元件
，并且讀寫資料庫時都
多了一步cache操作
總結
為了解決主從資料庫讀取舊資料的問題，常用的方案有四種：
（1）半同步複制
（2）強制讀主
（3）資料庫中間件
（4）緩存記錄寫key