本文轉(zhuǎn)載自微信公眾號(hào)「moon聊技術(shù)」，作者 moon聊技術(shù)。轉(zhuǎn)載本文請(qǐng)聯(lián)系 moon聊技術(shù)公眾號(hào)。

成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供泗縣網(wǎng)站建設(shè)、泗縣做網(wǎng)站、泗縣網(wǎng)站設(shè)計(jì)、泗縣網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、泗縣企業(yè)網(wǎng)站模板建站服務(wù)，十余年泗縣做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

什么是雙寫?

我們開門見山，這個(gè)很好理解，雙寫就是說，一份數(shù)據(jù)在數(shù)據(jù)庫存一份，在緩存中也存一份，給緩存一個(gè)過期時(shí)間，當(dāng)讀不到緩存時(shí)從數(shù)據(jù)庫讀出來然后寫入緩存。

為什么需要雙寫呢?

當(dāng)請(qǐng)求量越來越大的時(shí)候，系統(tǒng)會(huì)慢慢出現(xiàn)瓶頸，由于數(shù)據(jù)庫的鏈接是有限的，無法支撐較高的QPS，所以我們要想一個(gè)辦法分擔(dān)數(shù)據(jù)庫的壓力，于是就有了雙寫，將數(shù)據(jù)寫入緩存，客戶端讀取數(shù)據(jù)直接從緩存中讀取，這樣就可以提高系統(tǒng)的性能。

但是如果要使用雙寫，那么不管是先更新緩存還是先更新mysql，總會(huì)有時(shí)間間隔，那么就要保證你的業(yè)務(wù)在一定程度上允許短暫的數(shù)據(jù)不一致的情況出現(xiàn)，否則，還是不建議使用的.

那么就有人問了?雙寫一定不能保證強(qiáng)一致性嗎?

答案是可以，只要把所有與其相關(guān)的讀寫請(qǐng)求用隊(duì)列串行化，這樣就可以保證雙寫的強(qiáng)一致性了，但是這樣會(huì)極大的降低系統(tǒng)的QPS，非常不推薦這種做法。

既然要雙寫，那么肯定會(huì)出現(xiàn)數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的情況，要怎樣去避免呢?

雙寫不一致問題要怎么解決

一.先更新數(shù)據(jù)庫，再更新緩存

這種情況會(huì)有什么問題呢?我們看下圖:

首先a先更新數(shù)據(jù)庫，按照正常流程來走，緊接著要a線程刪除緩存，可是突然后面來了個(gè)b線程，并且a線程因?yàn)楦鞣N業(yè)務(wù)原因卡住了，導(dǎo)致b線程先完成了，之后a線程才更新緩存。這時(shí)突然有其他線程進(jìn)來讀數(shù)據(jù)，就會(huì)讀到a的數(shù)據(jù)，但是按照業(yè)務(wù)流程來走，應(yīng)該讀到b的數(shù)據(jù)，此時(shí)，就出現(xiàn)了數(shù)據(jù)錯(cuò)亂的問題。

• 1.線程a更新數(shù)據(jù)庫
• 2.線程b更新數(shù)據(jù)庫
• 3.線程b更新緩存
• 4.線程a更新緩存
• 5.其他線程讀數(shù)據(jù)(讀錯(cuò)了)

到這里我們會(huì)發(fā)現(xiàn)，直接更新緩存是有很大的問題的，而且很多時(shí)候，在復(fù)雜點(diǎn)的緩存場(chǎng)景，緩存不單單是數(shù)據(jù)庫中直接取出來的值，有可能是聯(lián)合其他的很多數(shù)據(jù)結(jié)合計(jì)算出來的一個(gè)值。

而且可能會(huì)有一種場(chǎng)景，我們經(jīng)常在更新數(shù)據(jù)庫后直接更新緩存，但是在此之間并沒有緩存被訪問的需求，這樣我們就做了很多無用功，付出了很多代價(jià)。

大家應(yīng)該對(duì)單例模式有所了解，其中有一種懶加載的思想，就是說，在你需要的時(shí)候再去加載，用在雙寫的情況下非常合適，也就有了下面這種先更新數(shù)據(jù)庫，再刪除緩存的模式。

二.先更新數(shù)據(jù)庫，再刪除緩存

這種情況又會(huì)有什么問題呢?

當(dāng)然，這還是一種有問題的方案，我們來跟著圖盤一盤。

1:線程a更新數(shù)據(jù)庫

2:程序掛了，沒來的及刪除緩存

3.其他線程來讀數(shù)據(jù)(全都是錯(cuò)的)

這種方案的問題一目了然，只要程序掛了，就會(huì)出現(xiàn)數(shù)據(jù)讀錯(cuò)的情況，真實(shí)的業(yè)務(wù)你是應(yīng)該讀到a線程的值，卻一直在讀之前的值。

那這種方案有沒有優(yōu)化呢?

當(dāng)然也有了，其實(shí)我們可以每次寫入都記錄日志，然后修改結(jié)束后也記錄日志，通過日志狀態(tài)來判斷是否寫入成功，

• 如果沒有寫入成功后續(xù)并且沒有新的寫入請(qǐng)求，就補(bǔ)寫，
• 否則不做處理。

但是這種情況也會(huì)出現(xiàn)不一致的問題，就是如果寫數(shù)據(jù)庫程序斷了，到下次恢復(fù)數(shù)據(jù)之前這段時(shí)間，還會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

并且如果是頻繁寫入的情況，很有可能日志機(jī)制沒有發(fā)揮作用，就有新數(shù)據(jù)寫入覆蓋，并且日志系統(tǒng)還要占用額外的資源。

我懂了!應(yīng)該先刪除緩存再更新數(shù)據(jù)庫，這樣就可以了!

三.先刪除緩存 再更新數(shù)據(jù)庫

來來來，繼續(xù)貼圖，是不是很熟悉?

這種方案會(huì)有問題嗎??當(dāng)然有，繼續(xù)盤道：

• 1:線程a刪除緩存
• 2:線程b刪除緩存
• 3:線程a卡了
• 4:線程b更新數(shù)據(jù)庫
• 5:線程a更新數(shù)據(jù)
• 6:其他線程讀數(shù)據(jù)，讀到了a的(又錯(cuò)了)

完了，這種情況居然也有問題，線程a到底行不行，每次都是你出事。

這種情況中間會(huì)有一段數(shù)據(jù)亂掉，但是隨著下次的更新數(shù)據(jù)還是會(huì)恢復(fù)正確。

難道終極方案是先刪除緩存，再更新數(shù)據(jù)庫，再更新緩存??

四.先刪除緩存，再更新數(shù)據(jù)庫，再刪除緩存

繼續(xù)貼圖

• 1.線程a刪除緩存
• 2.其他線程讀取數(shù)據(jù)，讀到的是a之前的數(shù)據(jù)
• 3.線程a更新數(shù)據(jù)庫
• 4.線程a刪除緩存
• 5.其他線程設(shè)置緩存數(shù)據(jù)，是a之前的數(shù)據(jù)(此時(shí)應(yīng)該是a的)

大家是不是又發(fā)現(xiàn)了，這種設(shè)計(jì)方案還是會(huì)有問題的，直到下次數(shù)據(jù)更新才有可能將數(shù)據(jù)恢復(fù)正確。

來吧，最后一種大家經(jīng)常討論的延時(shí)雙刪方案，我們一起盤一盤。

五.延時(shí)雙刪

go on

• 1.先刪除緩存
• 2.再寫數(shù)據(jù)庫
• 3.休眠一段時(shí)間(根據(jù)具體的業(yè)務(wù)時(shí)間來定)
• 4.再次刪除緩存

這里加了一個(gè)延時(shí)的操作，目的是確保 修改數(shù)據(jù)庫 -> 清空緩存前，其他事務(wù)的更改緩存操作已經(jīng)執(zhí)行完。

所有的寫操作以數(shù)據(jù)庫為準(zhǔn)，只要到達(dá)緩存過期時(shí)間，則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫中讀取新值然后回填緩存。

但這其中難免還是會(huì)大量的查詢到舊緩存數(shù)據(jù)的，因?yàn)檠訒r(shí)時(shí)間是根據(jù)業(yè)務(wù)自己定義的，時(shí)間太長(zhǎng)和太短在高并發(fā)情況下都會(huì)有查詢到臟數(shù)據(jù)的情況產(chǎn)生。

這樣最差的情況就是在超時(shí)時(shí)間內(nèi)數(shù)據(jù)存在不一致。

結(jié)語

到這里大家應(yīng)該會(huì)發(fā)現(xiàn)，除了串行化這種方式以外，其他無論哪種方式大大小小都會(huì)有數(shù)據(jù)不一致的現(xiàn)象發(fā)生，有時(shí)為了維護(hù)數(shù)據(jù)一致性問題還要做很多額外很重的操作，比如加一些日志來做狀態(tài)處理雙寫問題，具體的方案選擇還是要根據(jù)業(yè)務(wù)的敏感度來定的。

新聞標(biāo)題：雙寫兜兜轉(zhuǎn)轉(zhuǎn)，又回到了串行化的方式
URL鏈接：http://uogjgqi.cn/article/dhooede.html