快捷導(dǎo)航

面試常問(wèn)：如何保證Redis緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性

更新時(shí)間：2021年09月27日 16:25:06 作者：不會(huì)編程的派大星

在實(shí)際開(kāi)發(fā)過(guò)程中，緩存的使用頻率是非常高的，只要使用緩存和數(shù)據(jù)庫(kù)存儲(chǔ)，就難免會(huì)出現(xiàn)雙寫(xiě)時(shí)數(shù)據(jù)一致性的問(wèn)題，那我們又該如何解決呢

一、一致性

1、強(qiáng)一致性

如果你的項(xiàng)目對(duì)緩存的要求是強(qiáng)一致性的，那么請(qǐng)不要使用緩存。這種一致性級(jí)別是最符合用戶(hù)直覺(jué)的，它要求系統(tǒng)寫(xiě)入什么，讀出來(lái)的也會(huì)是什么，用戶(hù)體驗(yàn)好，但實(shí)現(xiàn)起來(lái)往往對(duì)系統(tǒng)的性能影響大。

2、弱一致性

這種一致性級(jí)別約束了系統(tǒng)在寫(xiě)入成功后，不承諾立即可以讀到寫(xiě)入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別（比如秒級(jí)別）后，數(shù)據(jù)能夠達(dá)到一致?tīng)顟B(tài)。

3、最終一致性

最終一致性是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨(dú)提出來(lái)，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。一般情況下，高可用只確保最終一致性，不確保強(qiáng)一致性。

強(qiáng)一致性，讀請(qǐng)求和寫(xiě)請(qǐng)求會(huì)串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣會(huì)大大增加系統(tǒng)的處理效率，吞吐量也會(huì)大大降低。

二、redis緩存和mysql數(shù)據(jù)庫(kù)數(shù)據(jù)一致性解決

在這里插入圖片描述

這張圖，大多數(shù)人的很多業(yè)務(wù)操作都是根據(jù)這個(gè)圖來(lái)做緩存的。但是一旦設(shè)計(jì)到雙寫(xiě)或者
數(shù)據(jù)庫(kù)和緩存更新等操作，就很容易出現(xiàn)數(shù)據(jù)一致性的問(wèn)題。無(wú)論是先寫(xiě)數(shù)據(jù)庫(kù)，在刪除緩存，還是先刪除緩存，在寫(xiě)入數(shù)據(jù)庫(kù)，都會(huì)出現(xiàn)數(shù)據(jù)一致性的問(wèn)題。列舉兩個(gè)小例子。

1、先刪除了redis緩存，但是因?yàn)槠渌裁丛蜻€沒(méi)來(lái)得及寫(xiě)入數(shù)據(jù)庫(kù)，另外一個(gè)線程就來(lái)讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫(kù)讀取到之前的數(shù)據(jù)并寫(xiě)入緩存，此時(shí)緩存中為臟數(shù)據(jù)。

2、如果先寫(xiě)入了數(shù)據(jù)庫(kù)，但是在緩存被刪除前，寫(xiě)入數(shù)據(jù)庫(kù)的線程因?yàn)槠渌虮恢袛嗔?，沒(méi)有刪除掉緩存，就也會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

總的來(lái)說(shuō)，寫(xiě)和讀在多數(shù)情況下都是并發(fā)的，不能絕對(duì)保證先后順序，就會(huì)很容易出現(xiàn)緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)不一致的情況，還怎么解決呢？

1、方案一：采用延時(shí)雙刪策略

基本思路：在寫(xiě)庫(kù)前后都進(jìn)行刪除緩存操作，并且設(shè)置合理的超時(shí)時(shí)間
基本步驟：先刪除緩存–再寫(xiě)數(shù)據(jù)庫(kù)—休眠一段時(shí)間—再次刪除緩存
注：休眠的時(shí)間是根據(jù)自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)來(lái)確定的。這樣做主要是為了保證在寫(xiě)請(qǐng)求之前確保讀請(qǐng)求結(jié)束，寫(xiě)請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

該方案的弊端：集合雙刪策略+緩存超時(shí)策略設(shè)置，這樣最差的結(jié)果就是在超時(shí)時(shí)間內(nèi)數(shù)據(jù)存在不一致，又增加了寫(xiě)請(qǐng)求的耗時(shí)。

2、方案二：一步更新緩存（基于訂閱Binlog的同步機(jī)制）

基本思路： mysql Binlog增強(qiáng)訂閱消費(fèi)+消息隊(duì)列+增量數(shù)據(jù)更新到redis—讀redis：熱數(shù)據(jù)基本上都在redis—寫(xiě)mysql：增刪改都是操作mysql—更新redis數(shù)據(jù)：mysql的數(shù)據(jù)操作Binlog，來(lái)更新redis

我們?cè)賮?lái)看看詳細(xì)的過(guò)程

1、Redis更新

1）、數(shù)據(jù)操作主要分為兩大塊：
一個(gè)是全量，將全部數(shù)據(jù)寫(xiě)去redis；另一個(gè)就是增量（update、insert、delete），實(shí)時(shí)更新。

2）、讀取binlog后分析，利用消息隊(duì)列,推送更新各臺(tái)的redis緩存數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫(xiě)入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對(duì)Redis進(jìn)行更新。
其實(shí)這種機(jī)制，很類(lèi)似MySQL的主從備份機(jī)制，因?yàn)镸ySQL的主備也是通過(guò)binlog來(lái)實(shí)現(xiàn)的數(shù)據(jù)一致性。

這里可以結(jié)合使用canal(阿里的一款開(kāi)源框架)，通過(guò)該框架可以對(duì)MySQL的binlog進(jìn)行訂閱，而canal正是模仿了mysql的slave數(shù)據(jù)庫(kù)的備份請(qǐng)求，使得Redis的數(shù)據(jù)更新達(dá)到了相同的效果。

當(dāng)然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來(lái)實(shí)現(xiàn)推送更新Redis。

歡迎小伙伴們留言討論！

以上就是面試官常問(wèn)：如何保證Redis緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性的詳細(xì)內(nèi)容，更多關(guān)于Redis緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)一致的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: