1.忍受大法

第一種解決辦法，很簡(jiǎn)單，無他，不管他，沒有讀到也沒事。這時(shí)業(yè)務(wù)不需要任何改造，你好，我好，她也好~

如果業(yè)務(wù)對(duì)于數(shù)據(jù)一致性要求不高，我們就可以采用這種方案。

2.數(shù)據(jù)同步寫方案

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

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

• 業(yè)務(wù)系統(tǒng)發(fā)起寫操作，數(shù)據(jù)寫主庫
• 寫請(qǐng)求需要等待主從同步完成才能返回
• 數(shù)據(jù)讀從庫，主從同步完成就能讀到最新數(shù)據(jù)

這種方案，我們只需要修改數(shù)據(jù)庫之間同步配置即可，業(yè)務(wù)層無需修改，相對(duì)簡(jiǎn)單。

「不過，由于主庫寫需要等待主從完成，寫請(qǐng)求的時(shí)延將會(huì)增加，吞吐量將會(huì)降低?！?/p>

這一點(diǎn)對(duì)于現(xiàn)在在線業(yè)務(wù)，可能無法接受。

3.選擇性強(qiáng)制讀主

對(duì)于需要強(qiáng)一致的場(chǎng)景，我們可以將其的讀請(qǐng)求都操作主庫，這樣「讀寫都在主庫」，就沒有不一致的情況。

這種方案業(yè)務(wù)層需要改造一下，將其強(qiáng)制性讀主，相對(duì)改造難度較低。

不過這種方案相對(duì)于浪費(fèi)了另一個(gè)數(shù)據(jù)庫，增加主庫的壓力。

4.中間件選擇路由法

這種方案需要使用一個(gè)中間件，所有數(shù)據(jù)庫操作都先發(fā)到中間件，由中間件再分發(fā)到相應(yīng)的數(shù)據(jù)庫。

這時(shí)流程如下：

• 寫請(qǐng)求，中間件將會(huì)發(fā)到主庫，同時(shí)記錄一下此時(shí)寫請(qǐng)求的 key（操作表加主鍵等）
• 讀請(qǐng)求，如果此時(shí) key 存在，將會(huì)路由到主庫
• 一定時(shí)間后（經(jīng)驗(yàn)值），中間件認(rèn)為主從同步完成，刪除這個(gè) key，后續(xù)讀將會(huì)讀從庫

這種方案，可以保持?jǐn)?shù)據(jù)讀寫的一致。

但是系統(tǒng)架構(gòu)增加了一個(gè)中間件，整體復(fù)雜度變高，業(yè)務(wù)開發(fā)也變得復(fù)雜，學(xué)習(xí)成本也比較高。

5.緩存路由大法

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

這時(shí)流程如下:

1. 寫請(qǐng)求發(fā)往主庫，同時(shí)緩存記錄操作的 key，緩存的失效時(shí)間設(shè)置為主從的延時(shí)
2. 讀請(qǐng)求首先判斷緩存是否存在

• 若存在，代表剛發(fā)生過寫操作，讀請(qǐng)求操作主庫
• 若不存在，代表近期沒發(fā)生寫操作，讀請(qǐng)求操作從庫

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

總結(jié)

我們引入主從架構(gòu)，數(shù)據(jù)讀寫分離，目的是為了解決業(yè)務(wù)快速發(fā)展,請(qǐng)求量變大，并發(fā)量變大，從而引發(fā)的數(shù)據(jù)庫的讀瓶頸。

不過當(dāng)引入新一個(gè)架構(gòu)解決問題時(shí)，勢(shì)必會(huì)帶來另外一個(gè)問題，數(shù)據(jù)庫讀寫分離之后，主從延遲從而導(dǎo)致數(shù)據(jù)不一致的情況。，

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

• 忍受大法
• 數(shù)據(jù)庫同步寫方案
• 選擇性強(qiáng)制讀主
• 中間件選擇路由法
• 緩存路由大法

到此這篇關(guān)于Mysql主從延時(shí)圖解方法的文章就介紹到這了,更多相關(guān)Mysql主從延時(shí) 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論