建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是蘇三，又跟大家見面了。
成都創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站、網(wǎng)站重做改版、武平網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5開發(fā)、成都做商城網(wǎng)站、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為武平等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
前言
數(shù)據(jù)庫和緩存(比如：redis)雙寫數(shù)據(jù)一致性問題，是一個跟開發(fā)語言無關(guān)的公共問題。尤其在高并發(fā)的場景下，這個問題變得更加嚴(yán)重。
我很負(fù)責(zé)的告訴大家，該問題無論在面試，還是工作中遇到的概率非常大，所以非常有必要跟大家一起探討一下。
今天這篇文章我會從淺入深，跟大家一起聊聊，數(shù)據(jù)庫和緩存雙寫數(shù)據(jù)一致性問題常見的解決方案，這些方案中可能存在的坑，以及最優(yōu)方案是什么。
1、 常見方案
通常情況下，我們使用緩存的主要目的是為了提升查詢的性能。大多數(shù)情況下，我們是這樣使用緩存
的：
- 用戶請求過來之后，先查緩存有沒有數(shù)據(jù)，如果有則直接返回。
- 如果緩存沒數(shù)據(jù)，再繼續(xù)查數(shù)據(jù)庫。
- 如果數(shù)據(jù)庫有數(shù)據(jù)，則將查詢出來的數(shù)據(jù)，放入緩存中，然后返回該數(shù)據(jù)。
- 如果數(shù)據(jù)庫也沒數(shù)據(jù)，則直接返回空。
這是緩存非常常見的用法。一眼看上去，好像沒有啥問題。
但你忽略了一個非常重要的細(xì)節(jié)：如果數(shù)據(jù)庫中的某條數(shù)據(jù)，放入緩存之后，又立馬被更新了，那么該如何更新緩存呢?
不更新緩存行不行?
答：當(dāng)然不行，如果不更新緩存，在很長的一段時間內(nèi)(決定于緩存的過期時間)，用戶請求從緩存中獲取到的都可能是舊值，而非數(shù)據(jù)庫的最新值。這不是有數(shù)據(jù)不一致的問題?
那么，我們該如何更新緩存呢?
目前有以下4種方案：
- 先寫緩存，再寫數(shù)據(jù)庫。
- 先寫數(shù)據(jù)庫，再寫緩存。
- 先刪緩存，再寫數(shù)據(jù)庫。
- 先寫數(shù)據(jù)庫，再刪緩存。
接下來，我們詳細(xì)說說這4種方案。
2、先寫緩存，再寫數(shù)據(jù)庫
對于更新緩存的方案，很多人第一個想到的可能是在寫操作中直接更新緩存(寫緩存)，更直接明了。
那么，問題來了：在寫操作中，到底是先寫緩存，還是先寫數(shù)據(jù)庫呢?
我們在這里先聊聊先寫緩存，再寫數(shù)據(jù)庫的情況，因?yàn)樗膯栴}最嚴(yán)重。
某一個用戶的每一次寫操作，如果剛寫完緩存，突然網(wǎng)絡(luò)出現(xiàn)了異常，導(dǎo)致寫數(shù)據(jù)庫失敗了。
其結(jié)果是緩存更新成了最新數(shù)據(jù)，但數(shù)據(jù)庫沒有，這樣緩存中的數(shù)據(jù)不就變成臟數(shù)據(jù)了?如果此時該用戶的查詢請求，正好讀取到該數(shù)據(jù)，就會出現(xiàn)問題，因?yàn)樵摂?shù)據(jù)在數(shù)據(jù)庫中根本不存在，這個問題非常嚴(yán)重。
我們都知道，緩存的主要目的是把數(shù)據(jù)庫的數(shù)據(jù)臨時保存在內(nèi)存，便于后續(xù)的查詢，提升查詢速度。
但如果某條數(shù)據(jù)，在數(shù)據(jù)庫中都不存在，你緩存這種“假數(shù)據(jù)”又有啥意義呢?
因此，先寫緩存，再寫數(shù)據(jù)庫的方案是不可取的，在實(shí)際工作中用得不多。
3、 先寫數(shù)據(jù)庫，再寫緩存
既然上面的方案行不通，接下來，聊聊先寫數(shù)據(jù)庫，再寫緩存的方案，該方案在低并發(fā)編程中有人在用(我猜的)。 用戶的寫操作，先寫數(shù)據(jù)庫，再寫緩存，可以避免之前“假數(shù)據(jù)”的問題。但它卻帶來了新的問題。
什么問題呢?
（1）寫緩存失敗了
如果把寫數(shù)據(jù)庫和寫緩存操作，放在同一個事務(wù)當(dāng)中，當(dāng)寫緩存失敗了，我們可以把寫入數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行回滾。
如果是并發(fā)量比較小，對接口性能要求不太高的系統(tǒng)，可以這么玩。
但如果在高并發(fā)的業(yè)務(wù)場景中，寫數(shù)據(jù)庫和寫緩存，都屬于遠(yuǎn)程操作。為了防止出現(xiàn)大事務(wù)，造成的死鎖問題，通常建議寫數(shù)據(jù)庫和寫緩存不要放在同一個事務(wù)中。
也就是說在該方案中，如果寫數(shù)據(jù)庫成功了，但寫緩存失敗了，數(shù)據(jù)庫中已寫入的數(shù)據(jù)不會回滾。
這就會出現(xiàn)：數(shù)據(jù)庫是新數(shù)據(jù)，而緩存是舊數(shù)據(jù)，兩邊數(shù)據(jù)不一致的情況。
（2） 高并發(fā)下的問題
假設(shè)在高并發(fā)的場景中，針對同一個用戶的同一條數(shù)據(jù)，有兩個寫數(shù)據(jù)請求：a和b，它們同時請求到業(yè)務(wù)系統(tǒng)。
其中請求a獲取的是舊數(shù)據(jù)，而請求b獲取的是新數(shù)據(jù)，如下圖所示：
- 請求a先過來，剛寫完了數(shù)據(jù)庫。但由于網(wǎng)絡(luò)原因，卡頓了一下，還沒來得及寫緩存。
- 這時候請求b過來了，先寫了數(shù)據(jù)庫。
- 接下來，請求b順利寫了緩存。
- 此時，請求a卡頓結(jié)束，也寫了緩存。
很顯然，在這個過程當(dāng)中，請求b在緩存中的新數(shù)據(jù)，被請求a的舊數(shù)據(jù)覆蓋了。
也就是說：在高并發(fā)場景中，如果多個線程同時執(zhí)行先寫數(shù)據(jù)庫，再寫緩存的操作，可能會出現(xiàn)數(shù)據(jù)庫是新值，而緩存中是舊值，兩邊數(shù)據(jù)不一致的情況。
（3） 浪費(fèi)系統(tǒng)資源
該方案還有一個比較大的問題就是：每個寫操作，寫完數(shù)據(jù)庫，會馬上寫緩存，比較浪費(fèi)系統(tǒng)資源。
為什么這么說呢?
你可以試想一下，如果寫的緩存，并不是簡單的數(shù)據(jù)內(nèi)容，而是要經(jīng)過非常復(fù)雜的計算得出的最終結(jié)果。這樣每寫一次緩存，都需要經(jīng)過一次非常復(fù)雜的計算，不是非常浪費(fèi)系統(tǒng)資源嗎?
尤其是cpu和內(nèi)存資源。
還有些業(yè)務(wù)場景比較特殊：寫多讀少。
如果在這類業(yè)務(wù)場景中，每個用的寫操作，都需要寫一次緩存，有點(diǎn)得不償失。
由此可見，在高并發(fā)的場景中，先寫數(shù)據(jù)庫，再寫緩存，這套方案問題挺多的，也不太建議使用。
如果你已經(jīng)用了，趕緊看看踩坑了沒?
4、 先刪緩存，再寫數(shù)據(jù)庫
通過上面的內(nèi)容我們得知，如果直接更新緩存的問題很多。
那么，為何我們不能換一種思路：不去直接更新緩存，而改為刪除緩存呢?
刪除緩存方案，同樣有兩種：
- 先刪緩存，再寫數(shù)據(jù)庫。
- 先寫數(shù)據(jù)庫，再刪緩存。
我們一起先看看：先刪緩存，再寫數(shù)據(jù)庫的情況。
說白了，在用戶的寫操作中，先執(zhí)行刪除緩存操作，再去寫數(shù)據(jù)庫。這套方案，可以是可以，但也會有一樣問題。
（1）高并發(fā)下的問題
假設(shè)在高并發(fā)的場景中，同一個用戶的同一條數(shù)據(jù)，有一個讀數(shù)據(jù)請求c，還有另一個寫數(shù)據(jù)請求d(一個更新操作)，同時請求到業(yè)務(wù)系統(tǒng)。如下圖所示：
- 請求d先過來，把緩存刪除了。但由于網(wǎng)絡(luò)原因，卡頓了一下，還沒來得及寫數(shù)據(jù)庫。
- 這時請求c過來了，先查緩存發(fā)現(xiàn)沒數(shù)據(jù)，再查數(shù)據(jù)庫，有數(shù)據(jù)，但是舊值。
- 請求c將數(shù)據(jù)庫中的舊值，更新到緩存中。
- 此時，請求d卡頓結(jié)束，把新值寫入數(shù)據(jù)庫。
在這個過程當(dāng)中，請求d的新值并沒有被請求c寫入緩存，同樣會導(dǎo)致緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致的情況。
那么，這種場景的數(shù)據(jù)不一致問題，能否解決呢?
（2） 緩存雙刪
在上面的業(yè)務(wù)場景中，一個讀數(shù)據(jù)請求，一個寫數(shù)據(jù)請求。當(dāng)寫數(shù)據(jù)請求把緩存刪了之后，讀數(shù)據(jù)請求，可能把當(dāng)時從數(shù)據(jù)庫查詢出來的舊值，寫入緩存當(dāng)中。
有人說還不好辦，請求d在寫完數(shù)據(jù)庫之后，把緩存重新刪一次不就行了?
這就是我們所說的緩存雙刪，即在寫數(shù)據(jù)庫之前刪除一次，寫完數(shù)據(jù)庫后，再刪除一次。
該方案有個非常關(guān)鍵的地方是：第二次刪除緩存，并非立馬就刪，而是要在一定的時間間隔之后。
我們再重新回顧一下，高并發(fā)下一個讀數(shù)據(jù)請求，一個寫數(shù)據(jù)請求導(dǎo)致數(shù)據(jù)不一致的產(chǎn)生過程：
- 請求d先過來，把緩存刪除了。但由于網(wǎng)絡(luò)原因，卡頓了一下，還沒來得及寫數(shù)據(jù)庫。
- 這時請求c過來了，先查緩存發(fā)現(xiàn)沒數(shù)據(jù)，再查數(shù)據(jù)庫，有數(shù)據(jù)，但是舊值。
- 請求c將數(shù)據(jù)庫中的舊值，更新到緩存中。
- 此時，請求d卡頓結(jié)束，把新值寫入數(shù)據(jù)庫。
- 一段時間之后，比如：500ms，請求d將緩存刪除。
這樣來看確實(shí)可以解決緩存不一致問題。
那么，為什么一定要間隔一段時間之后，才能刪除緩存呢?
請求d卡頓結(jié)束，把新值寫入數(shù)據(jù)庫后，請求c將數(shù)據(jù)庫中的舊值，更新到緩存中。
此時，如果請求d刪除太快，在請求c將數(shù)據(jù)庫中的舊值更新到緩存之前，就已經(jīng)把緩存刪除了，這次刪除就沒任何意義。必須要在請求c更新緩存之后，再刪除緩存，才能把舊值及時刪除了。
所以需要在請求d中加一個時間間隔，確保請求c，或者類似于請求c的其他請求，如果在緩存中設(shè)置了舊值，最終都能夠被請求d刪除掉。
接下來，還有一個問題：如果第二次刪除緩存時，刪除失敗了該怎么辦?
這里先留點(diǎn)懸念，后面會詳細(xì)說。
5、 先寫數(shù)據(jù)庫，再刪緩存
從前面得知，先刪緩存，再寫數(shù)據(jù)庫，在并發(fā)的情況下，也可能會出現(xiàn)緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致的情況。
那么，我們只能寄希望于最后的方案了。
接下來，我們重點(diǎn)看看先寫數(shù)據(jù)庫，再刪緩存的方案。
在高并發(fā)的場景中，有一個讀數(shù)據(jù)請求，有一個寫數(shù)據(jù)請求，更新過程如下：
- 請求e先寫數(shù)據(jù)庫，由于網(wǎng)絡(luò)原因卡頓了一下，沒有來得及刪除緩存。
- 請求f查詢緩存，發(fā)現(xiàn)緩存中有數(shù)據(jù)，直接返回該數(shù)據(jù)。
- 請求e刪除緩存。
在這個過程中，只有請求f讀了一次舊數(shù)據(jù)，后來舊數(shù)據(jù)被請求e及時刪除了，看起來問題不大。
但如果是讀數(shù)據(jù)請求先過來呢?
- 請求f查詢緩存，發(fā)現(xiàn)緩存中有數(shù)據(jù)，直接返回該數(shù)據(jù)。
- 請求e先寫數(shù)據(jù)庫。
- 請求e刪除緩存。
這種情況看起來也沒問題呀?
答：對的。
但就怕出現(xiàn)下面這種情況，即緩存自己失效了。如下圖所示：
- 緩存過期時間到了，自動失效。
- 請求f查詢緩存，發(fā)緩存中沒有數(shù)據(jù)，查詢數(shù)據(jù)庫的舊值，但由于網(wǎng)絡(luò)原因卡頓了，沒有來得及更新緩存。
- 請求e先寫數(shù)據(jù)庫，接著刪除了緩存。
- 請求f更新舊值到緩存中。
這時，緩存和數(shù)據(jù)庫的數(shù)據(jù)同樣出現(xiàn)不一致的情況了。
但這種情況還是比較少的，需要同時滿足以下條件才可以：
- 緩存剛好自動失效。
- 請求f從數(shù)據(jù)庫查出舊值，更新緩存的耗時，比請求e寫數(shù)據(jù)庫，并且刪除緩存的還長。
我們都知道查詢數(shù)據(jù)庫的速度，一般比寫數(shù)據(jù)庫要快，更何況寫完數(shù)據(jù)庫，還要刪除緩存。所以絕大多數(shù)情況下，寫數(shù)據(jù)請求比讀數(shù)據(jù)情況耗時更長。
由此可見，系統(tǒng)同時滿足上述兩個條件的概率非常小。
推薦大家使用先寫數(shù)據(jù)庫，再刪緩存的方案，雖說不能100%避免數(shù)據(jù)不一致問題，但出現(xiàn)該問題的概率，相對于其他方案來說是最小的。
但在該方案中，如果刪除緩存失敗了該怎么辦呢?
6、 刪緩存失敗怎么辦?
先寫數(shù)據(jù)庫，再刪緩存的方案，跟緩存雙刪的方案一樣，有一個共同的風(fēng)險點(diǎn)，即：如果緩存刪除失敗了，也會導(dǎo)致緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致。
那么，刪除緩存失敗怎么辦呢?
答：需要加重試機(jī)制。
在接口中如果更新了數(shù)據(jù)庫成功了，但更新緩存失敗了，可以立刻重試3次。如果其中有任何一次成功，則直接返回成功。如果3次都失敗了，則寫入數(shù)據(jù)庫，準(zhǔn)備后續(xù)再處理。
當(dāng)然，如果你在接口中直接同步重試，該接口并發(fā)量比較高的時候，可能有點(diǎn)影響接口性能。
這時，就需要改成異步重試了。
異步重試方式有很多種，比如：
- 每次都單獨(dú)起一個線程，該線程專門做重試的工作。但如果在高并發(fā)的場景下，可能會創(chuàng)建太多的線程，導(dǎo)致系統(tǒng)OOM問題，不太建議使用。
- 將重試的任務(wù)交給線程池處理，但如果服務(wù)器重啟，部分?jǐn)?shù)據(jù)可能會丟失。
- 將重試數(shù)據(jù)寫表，然后使用elastic-job等定時任務(wù)進(jìn)行重試。
- 將重試的請求寫入mq等消息中間件中，在mq的consumer中處理。
- 訂閱mysql的binlog，在訂閱者中，如果發(fā)現(xiàn)了更新數(shù)據(jù)請求，則刪除相應(yīng)的緩存。
7、 定時任務(wù)
使用定時任務(wù)重試的具體方案如下：
當(dāng)用戶操作寫完數(shù)據(jù)庫，但刪除緩存失敗了，需要將用戶數(shù)據(jù)寫入重試表中。如下圖所示：
在定時任務(wù)中，異步讀取重試表中的用戶數(shù)據(jù)。重試表需要記錄一個重試次數(shù)字段，初始值為0。然后重試5次，不斷刪除緩存，每重試一次該字段值+1。如果其中有任意一次成功了，則返回成功。如果重試了5次，還是失敗，則我們需要在重試表中記錄一個失敗的狀態(tài)，等待后續(xù)進(jìn)一步處理。
在高并發(fā)場景中，定時任務(wù)推薦使用elastic-job。相對于xxl-job等定時任務(wù)，它可以分片處理，提升處理速度。同時每片的間隔可以設(shè)置成：1,2,3,5,7秒等。
如果大家對定時任務(wù)比較感興趣的話，可以看看我的另一篇文章《學(xué)會這10種定時任務(wù)，我有點(diǎn)飄了》，里面列出了目前最主流的定時任務(wù)。
使用定時任務(wù)重試的話，有個缺點(diǎn)就是實(shí)時性沒那么高，對于實(shí)時性要求特別高的業(yè)務(wù)場景，該方案不太適用。但是對于一般場景，還是可以用一用的。
但它有一個很大的優(yōu)點(diǎn)，即數(shù)據(jù)是落庫的，不會丟數(shù)據(jù)。
8、mq
在高并發(fā)的業(yè)務(wù)場景中，mq(消息隊(duì)列)是必不可少的技術(shù)之一。它不僅可以異步解耦，還能削峰填谷。對保證系統(tǒng)的穩(wěn)定性是非常有意義的。
對mq有興趣的朋友可以看看我的另一篇文章《mq的那些破事兒》。
mq的生產(chǎn)者，生產(chǎn)了消息之后，通過指定的topic發(fā)送到mq服務(wù)器。然后mq的消費(fèi)者，訂閱該topic的消息，讀取消息數(shù)據(jù)之后，做業(yè)務(wù)邏輯處理。
使用mq重試的具體方案如下：
- 當(dāng)用戶操作寫完數(shù)據(jù)庫，但刪除緩存失敗了，產(chǎn)生一條mq消息，發(fā)送給mq服務(wù)器。
- mq消費(fèi)者讀取mq消息，重試5次刪除緩存。如果其中有任意一次成功了，則返回成功。如果重試了5次，還是失敗，則寫入死信隊(duì)列中。
- 推薦mq使用rocketmq，重試機(jī)制和死信隊(duì)列默認(rèn)是支持的。使用起來非常方便，而且還支持順序消息，延遲消息和事務(wù)消息等多種業(yè)務(wù)場景。
當(dāng)然在該方案中，刪除緩存可以完全走異步。即用戶的寫操作，在寫完數(shù)據(jù)庫之后，不用立刻刪除一次緩存。而直接發(fā)送mq消息，到mq服務(wù)器，然后有mq消費(fèi)者全權(quán)負(fù)責(zé)刪除緩存的任務(wù)。
因?yàn)閙q的實(shí)時性還是比較高的，因此改良后的方案也是一種不錯的選擇。
9、 binlog
前面我們聊過的，無論是定時任務(wù)，還是mq(消息隊(duì)列)，做重試機(jī)制，對業(yè)務(wù)都有一定的侵入性。
在使用定時任務(wù)的方案中，需要在業(yè)務(wù)代碼中增加額外邏輯，如果刪除緩存失敗，需要將數(shù)據(jù)寫入重試表。
而使用mq的方案中，如果刪除緩存失敗了，需要在業(yè)務(wù)代碼中發(fā)送mq消息到mq服務(wù)器。
其實(shí)，還有一種更優(yōu)雅的實(shí)現(xiàn)，即監(jiān)聽binlog，比如使用：canal等中間件。
具體方案如下：
- 在業(yè)務(wù)接口中寫數(shù)據(jù)庫之后，就不管了，直接返回成功。
- mysql服務(wù)器會自動把變更的數(shù)據(jù)寫入binlog中。
- binlog訂閱者獲取變更的數(shù)據(jù)，然后刪除緩存。
這套方案中業(yè)務(wù)接口確實(shí)簡化了一些流程，只用關(guān)心數(shù)據(jù)庫操作即可，而在binlog訂閱者中做緩存刪除工作。
但如果只是按照圖中的方案進(jìn)行刪除緩存，只刪除了一次，也可能會失敗。
如何解決這個問題呢?
答：這就需要加上前面聊過的重試機(jī)制了。如果刪除緩存失敗，寫入重試表，使用定時任務(wù)重試?；蛘邔懭雖q，讓mq自動重試。
在這里推薦使用mq自動重試機(jī)制。
在binlog訂閱者中如果刪除緩存失敗，則發(fā)送一條mq消息到mq服務(wù)器，在mq消費(fèi)者中自動重試5次。如果有任意一次成功，則直接返回成功。如果重試5次后還是失敗，則該消息自動被放入死信隊(duì)列，后面可能需要人工介入。
網(wǎng)頁名稱：如何保證數(shù)據(jù)庫和緩存雙寫一致性？
本文來源：http://www.dlmjj.cn/article/ccchdjs.html
