面試官:緩存一致性問題怎么解決?
關(guān)于Redis的其他的一些面試問題已經(jīng)寫過了,比如常見的緩存穿透、雪崩、擊穿、熱點的問題,但是還有一個比較麻煩的問題就是如何保證緩存一致性。
對于緩存和數(shù)據(jù)庫的操作,主要有以下兩種方式。
先刪緩存,再更新數(shù)據(jù)庫
先刪除緩存,數(shù)據(jù)庫還沒有更新成功,此時如果讀取緩存,緩存不存在,去數(shù)據(jù)庫中讀取到的是舊值,緩存不一致發(fā)生。
解決方案
延時雙刪
延時雙刪的方案的思路是,為了避免更新數(shù)據(jù)庫的時候,其他線程從緩存中讀取不到數(shù)據(jù),就在更新完數(shù)據(jù)庫之后,再sleep一段時間,然后再次刪除緩存。
sleep的時間要對業(yè)務(wù)讀寫緩存的時間做出評估,sleep時間大于讀寫緩存的時間即可。
流程如下:
-
線程1刪除緩存,然后去更新數(shù)據(jù)庫 -
線程2來讀緩存,發(fā)現(xiàn)緩存已經(jīng)被刪除,所以直接從數(shù)據(jù)庫中讀取,這時候由于線程1還沒有更新完成,所以讀到的是舊值,然后把舊值寫入緩存 -
線程1,根據(jù)估算的時間,sleep,由于sleep的時間大于線程2讀數(shù)據(jù)+寫緩存的時間,所以緩存被再次刪除 -
如果還有其他線程來讀取緩存的話,就會再次從數(shù)據(jù)庫中讀取到最新值
先更新數(shù)據(jù)庫,再刪除緩存
如果反過來操作,先更新數(shù)據(jù)庫,再刪除緩存呢?
這個就更明顯的問題了,更新數(shù)據(jù)庫成功,如果刪除緩存失敗或者還沒有來得及刪除,那么,其他線程從緩存中讀取到的就是舊值,還是會發(fā)生不一致。
解決方案
消息隊列
這是網(wǎng)上很多文章里都有寫過的方案。但是這個方案的缺陷會更明顯一點。
先更新數(shù)據(jù)庫,成功后往消息隊列發(fā)消息,消費到消息后再刪除緩存,借助消息隊列的重試機制來實現(xiàn),達(dá)到最終一致性的效果。
這個解決方案其實問題更多。
-
引入消息中間件之后,問題更復(fù)雜了,怎么保證消息不丟失更麻煩 -
就算更新數(shù)據(jù)庫和刪除緩存都沒有發(fā)生問題,消息的延遲也會帶來短暫的不一致性,不過這個延遲相對來說還是可以接受的
進(jìn)階版消息隊列
為了解決緩存一致性的問題單獨引入一個消息隊列,太復(fù)雜了。
其實,一般大公司本身都會有監(jiān)聽binlog消息的消息隊列存在,主要是為了做一些核對的工作。
這樣,我們可以借助監(jiān)聽binlog的消息隊列來做刪除緩存的操作。這樣做的好處是,不用你自己引入,侵入到你的業(yè)務(wù)代碼中,中間件幫你做了解耦,同時,中間件的這個東西本身就保證了高可用。
當(dāng)然,這樣消息延遲的問題依然存在,但是相比單純引入消息隊列的做法更好一點。
而且,如果并發(fā)不是特別高的話,這種做法的實時性和一致性都還算可以接受的。
其他解決方案
設(shè)置緩存過期時間
每次放入緩存的時候,設(shè)置一個過期時間,比如5分鐘,以后的操作只修改數(shù)據(jù)庫,不操作緩存,等待緩存超時后從數(shù)據(jù)庫重新讀取。
如果對于一致性要求不是很高的情況,可以采用這種方案。
這個方案還會有另外一個問題,就是如果數(shù)據(jù)更新的特別頻繁,不一致性的問題就很大了。
在實際生產(chǎn)中,我們有一些活動的緩存數(shù)據(jù)是使用這種方式處理的。
因為活動并不頻繁發(fā)生改變,而且對于活動來說,短暫的不一致性并不會有什么大的問題。
為什么是刪除,而不是更新緩存?
我們以先更新數(shù)據(jù)庫,再刪除緩存來舉例。
如果是更新的話,那就是先更新數(shù)據(jù)庫,再更新緩存。
舉個例子:如果數(shù)據(jù)庫1小時內(nèi)更新了1000次,那么緩存也要更新1000次,但是這個緩存可能在1小時內(nèi)只被讀取了1次,那么這1000次的更新有必要嗎?
反過來,如果是刪除的話,就算數(shù)據(jù)庫更新了1000次,那么也只是做了1次緩存刪除,只有當(dāng)緩存真正被讀取的時候才去數(shù)據(jù)庫加載。
總結(jié)
首先,我們要明確一點,緩存不是更新,而應(yīng)該是刪除。
刪除緩存有兩種方式:
-
先刪除緩存,再更新數(shù)據(jù)庫。解決方案是使用延遲雙刪。 -
先更新數(shù)據(jù)庫,再刪除緩存。解決方案是消息隊列或者其他binlog同步,引入消息隊列會帶來更多的問題,并不推薦直接使用。
針對緩存一致性要求不是很高的場景,那么只通過設(shè)置超時時間就可以了。
其實,如果不是很高的并發(fā),無論你選擇先刪緩存還是后刪緩存的方式,都幾乎很少能產(chǎn)生這種問題,但是在高并發(fā)下,你應(yīng)該知道怎么解決問題。
—————END—————
喜歡本文的朋友,歡迎關(guān)注公眾號?程序員小灰,收看更多精彩內(nèi)容
點個[在看],是對小灰最大的支持!
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!