DB主從一致性架構優化4種方法

2022-09-15 23:39:24 字數 2088 閱讀 3065

大部分網際網路的業務都是「讀多寫少」的場景,資料庫層面,讀效能往往成為瓶頸。如下圖:業界通常採用「一主多從,讀寫分離,冗餘多個讀庫」的資料庫架構來提公升資料庫的讀效能。

這種架構的乙個潛在缺點是,業務方有可能讀取到並不是最新的舊資料:

(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 很短的時...