Mysql主從延時圖解方法

Posted on by

1.忍受大法

第一種解決辦法，很簡單，無他，不管他，沒有讀到也沒事。這時業務不需要任何改造，你好，我好，她也好~

如果業務對於數據一致性要求不高，我們就可以采用這種方案。

2.數據同步寫方案

主從數據同步方案，一般都是采用的異步方式同步給備庫。

我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能返回。

  • 業務系統發起寫操作，數據寫主庫
  • 寫請求需要等待主從同步完成才能返回
  • 數據讀從庫，主從同步完成就能讀到最新數據

這種方案，我們隻需要修改數據庫之間同步配置即可，業務層無需修改，相對簡單。

「不過，由於主庫寫需要等待主從完成，寫請求的時延將會增加，吞吐量將會降低。」

這一點對於現在在線業務，可能無法接受。

3.選擇性強制讀主

對於需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣「讀寫都在主庫」，就沒有不一致的情況。

這種方案業務層需要改造一下，將其強制性讀主，相對改造難度較低。

不過這種方案相對於浪費瞭另一個數據庫，增加主庫的壓力。

4.中間件選擇路由法

這種方案需要使用一個中間件，所有數據庫操作都先發到中間件，由中間件再分發到相應的數據庫。

這時流程如下：

  • 寫請求，中間件將會發到主庫，同時記錄一下此時寫請求的 key（操作表加主鍵等）
  • 讀請求，如果此時 key 存在，將會路由到主庫
  • 一定時間後（經驗值），中間件認為主從同步完成，刪除這個 key，後續讀將會讀從庫

這種方案，可以保持數據讀寫的一致。

但是系統架構增加瞭一個中間件，整體復雜度變高，業務開發也變得復雜，學習成本也比較高。

5.緩存路由大法

這種方案與中間件的方案流程比較類似，不過改造成本相對較低，不需要增加任何中間件。

這時流程如下:

  1. 寫請求發往主庫，同時緩存記錄操作的 key，緩存的失效時間設置為主從的延時
  2. 讀請求首先判斷緩存是否存在
  • 若存在，代表剛發生過寫操作，讀請求操作主庫
  • 若不存在，代表近期沒發生寫操作，讀請求操作從庫

這種方案相對中間件的方案成本較低，但是呢我們此時又引入一個緩存組件，所有讀寫之間就又多瞭一步緩存操作。

總結

我們引入主從架構，數據讀寫分離，目的是為瞭解決業務快速發展,請求量變大，並發量變大，從而引發的數據庫的讀瓶頸。

不過當引入新一個架構解決問題時，勢必會帶來另外一個問題，數據庫讀寫分離之後，主從延遲從而導致數據不一致的情況。，

為瞭解決主從延遲，數據不一致的情況，我們可以采用以下這幾種方案：

  • 忍受大法
  • 數據庫同步寫方案
  • 選擇性強制讀主
  • 中間件選擇路由法
  • 緩存路由大法

到此這篇關於Mysql主從延時圖解方法的文章就介紹到這瞭,更多相關Mysql主從延時 內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：