面試常問:如何保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性
首先,我們先來看看有哪幾種一致性的情況呢?
一、一致性
1、強一致性
如果你的項目對緩存的要求是強一致性的,那么請不要使用緩存。這種一致性級別是最符合用戶直覺的,它要求系統(tǒng)寫入什么,讀出來的也會是什么,用戶體驗好,但實現(xiàn)起來往往對系統(tǒng)的性能影響大。
2、弱一致性
這種一致性級別約束了系統(tǒng)在寫入成功后,不承諾立即可以讀到寫入的值,也不承諾多久之后數(shù)據(jù)能夠達到一致,但會盡可能地保證到某個時間級別(比如秒級別)后,數(shù)據(jù)能夠達到一致狀態(tài)。
3、最終一致性
最終一致性是弱一致性的一個特例,系統(tǒng)會保證在一定時間內(nèi),能夠達到一個數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來,是因為它是弱一致性中非常推崇的一種一致性模型,也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。一般情況下,高可用只確保最終一致性,不確保強一致性。
強一致性,讀請求和寫請求會串行化,串到一個內(nèi)存隊列里去,這樣會大大增加系統(tǒng)的處理效率,吞吐量也會大大降低。
二、redis緩存和mysql數(shù)據(jù)庫數(shù)據(jù)一致性解決
這張圖,大多數(shù)人的很多業(yè)務(wù)操作都是根據(jù)這個圖來做緩存的。但是一旦設(shè)計到雙寫或者
數(shù)據(jù)庫和緩存更新等操作,就很容易出現(xiàn)數(shù)據(jù)一致性的問題。無論是先寫數(shù)據(jù)庫,在刪除緩存,還是先刪除緩存,在寫入數(shù)據(jù)庫,都會出現(xiàn)數(shù)據(jù)一致性的問題。列舉兩個小例子。
1、 先刪除了redis緩存,但是因為其他什么原因還沒來得及寫入數(shù)據(jù)庫,另外一個線程就來讀取,發(fā)現(xiàn)緩存為空,則去數(shù)據(jù)庫讀取到之前的數(shù)據(jù)并寫入緩存,此時緩存中為臟數(shù)據(jù)。
2、 如果先寫入了數(shù)據(jù)庫,但是在緩存被刪除前,寫入數(shù)據(jù)庫的線程因為其他原因被中斷了,沒有刪除掉緩存,就也會出現(xiàn)數(shù)據(jù)不一致的情況。
總的來說,寫和讀在多數(shù)情況下都是并發(fā)的,不能絕對保證先后順序,就會很容易出現(xiàn)緩存和數(shù)據(jù)庫數(shù)據(jù)不一致的情況,還怎么解決呢?
1、方案一:采用延時雙刪策略
基本思路: 在寫庫前后都進行刪除緩存操作,并且設(shè)置合理的超時時間
基本步驟: 先刪除緩存–再寫數(shù)據(jù)庫—休眠一段時間—再次刪除緩存
注:休眠的時間是根據(jù)自己的項目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時來確定的。這樣做主要是為了保證在寫請求之前確保讀請求結(jié)束,寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
該方案的弊端: 集合雙刪策略+緩存超時策略設(shè)置,這樣最差的結(jié)果就是在超時時間內(nèi)數(shù)據(jù)存在不一致,又增加了寫請求的耗時。
2、方案二:一步更新緩存(基于訂閱Binlog的同步機制)
基本思路: mysql Binlog增強訂閱消費+消息隊列+增量數(shù)據(jù)更新到redis—讀redis:熱數(shù)據(jù)基本上都在redis—寫mysql:增刪改都是操作mysql—更新redis數(shù)據(jù):mysql的數(shù)據(jù)操作Binlog,來更新redis
我們再來看看詳細的過程
1、Redis更新
1)、數(shù)據(jù)操作主要分為兩大塊:
一個是全量,將全部數(shù)據(jù)寫去redis;另一個就是增量(update、insert、delete),實時更新。
2)、讀取binlog后分析 ,利用消息隊列,推送更新各臺的redis緩存數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作,就可以把binlog相關(guān)的消息推送至Redis,Redis再根據(jù)binlog中的記錄,對Redis進行更新。
其實這種機制,很類似MySQL的主從備份機制,因為MySQL的主備也是通過binlog來實現(xiàn)的數(shù)據(jù)一致性。
這里可以結(jié)合使用canal(阿里的一款開源框架),通過該框架可以對MySQL的binlog進行訂閱,而canal正是模仿了mysql的slave數(shù)據(jù)庫的備份請求,使得Redis的數(shù)據(jù)更新達到了相同的效果。
當然,這里的消息推送工具你也可以采用別的第三方:kafka、rabbitMQ等來實現(xiàn)推送更新Redis。
歡迎小伙伴們留言討論!
以上就是面試官常問:如何保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性的詳細內(nèi)容,更多關(guān)于Redis緩存和數(shù)據(jù)庫數(shù)據(jù)一致的資料請關(guān)注腳本之家其它相關(guān)文章!
- 詳解redis緩存與數(shù)據(jù)庫一致性問題解決
- redis緩存一致性延時雙刪代碼實現(xiàn)方式
- 淺談一下如何保證Redis緩存與數(shù)據(jù)庫的一致性
- MySQL數(shù)據(jù)庫和Redis緩存一致性的更新策略
- redis分布式鎖解決緩存雙寫一致性
- redis緩存與數(shù)據(jù)庫一致性的問題及解決
- Redis解決緩存一致性問題
- Spring?Boot與Redis的緩存一致性問題解決
- Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性的問題解決
- Redis+Caffeine多級緩存數(shù)據(jù)一致性解決方案
- Redis 緩存雙寫一致性的解決方案
相關(guān)文章
基于redis實現(xiàn)的點贊功能設(shè)計思路詳解
點贊是我們現(xiàn)在經(jīng)常見到的一個效果,如朋友圈、微博都有點贊的效果,下面這篇文章主要跟大家分享了基于redis實現(xiàn)的點贊功能設(shè)計思路的相關(guān)資料,文中介紹的非常詳細,對大家實現(xiàn)點贊功能具有一定的參考學習價值,需要的朋友們下面來一起看看吧。2017-05-05Redis過期Key刪除策略和內(nèi)存淘汰策略的實現(xiàn)
當內(nèi)存使用達到上限,就無法存儲更多數(shù)據(jù)了,為了解決這個問題,Redis內(nèi)部會有兩套內(nèi)存回收的策略,過期Key刪除策略和內(nèi)存淘汰策略,本文就來詳細的介紹一下這兩種方法,感興趣的可以了解一下2024-02-02