本篇內(nèi)容介紹了“redis常見(jiàn)的面試題有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、重慶小程序開(kāi)發(fā)公司、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶(hù)創(chuàng)新互聯(lián)還提供了于洪免費(fèi)建站歡迎大家使用！

一、緩存雪崩

1.1 什么是緩存雪崩?

回顧一下我們?yōu)槭裁匆镁彺?Redis)：

為什么要緩存

現(xiàn)在有個(gè)問(wèn)題，如果我們的緩存掛掉了，這意味著我們的全部請(qǐng)求都跑去數(shù)據(jù)庫(kù)了。

如果緩存掛掉了，全部請(qǐng)求跑去數(shù)據(jù)庫(kù)了

在前面學(xué)習(xí)我們都知道Redis不可能把所有的數(shù)據(jù)都緩存起來(lái)(內(nèi)存昂貴且有限)，所以Redis需要對(duì)數(shù)據(jù)設(shè)置過(guò)期時(shí)間，并采用的是惰性刪除+定期刪除兩種策略對(duì)過(guò)期鍵刪除。Redis對(duì)過(guò)期鍵的策略+持久化

如果緩存數(shù)據(jù)設(shè)置的過(guò)期時(shí)間是相同的，并且Redis恰好將這部分?jǐn)?shù)據(jù)全部刪光了。這就會(huì)導(dǎo)致在這段時(shí)間內(nèi)，這些緩存同時(shí)失效，全部請(qǐng)求到數(shù)據(jù)庫(kù)中。

這就是緩存雪崩：

• Redis掛掉了，請(qǐng)求全部走數(shù)據(jù)庫(kù)。

• 對(duì)緩存數(shù)據(jù)設(shè)置相同的過(guò)期時(shí)間，導(dǎo)致某段時(shí)間內(nèi)緩存失效，請(qǐng)求全部走數(shù)據(jù)庫(kù)。

緩存雪崩如果發(fā)生了，很可能就把我們的數(shù)據(jù)庫(kù)搞垮，導(dǎo)致整個(gè)服務(wù)癱瘓!

1.2 如何解決緩存雪崩?

對(duì)于“對(duì)緩存數(shù)據(jù)設(shè)置相同的過(guò)期時(shí)間，導(dǎo)致某段時(shí)間內(nèi)緩存失效，請(qǐng)求全部走數(shù)據(jù)庫(kù)。”這種情況，非常好解決：

• 解決方法：在緩存的時(shí)候給過(guò)期時(shí)間加上一個(gè)隨機(jī)值，這樣就會(huì)大幅度的減少緩存在同一時(shí)間過(guò)期。

對(duì)于“Redis掛掉了，請(qǐng)求全部走數(shù)據(jù)庫(kù)”這種情況，我們可以有以下的思路：

• 事發(fā)前：實(shí)現(xiàn)Redis的高可用(主從架構(gòu)+Sentinel 或者Redis Cluster)，盡量避免Redis掛掉這種情況發(fā)生。

• 事發(fā)中：萬(wàn)一Redis真的掛了，我們可以設(shè)置本地緩存(ehcache)+限流(hystrix)，盡量避免我們的數(shù)據(jù)庫(kù)被干掉(起碼能保證我們的服務(wù)還是能正常工作的)

• 事發(fā)后：redis持久化，重啟后自動(dòng)從磁盤(pán)上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

二、緩存穿透

2.1 什么是緩存穿透

比如，我們有一張數(shù)據(jù)庫(kù)表，ID都是從1開(kāi)始的(正數(shù))：

隨便找了一張數(shù)據(jù)庫(kù)表

但是可能有黑客想把我的數(shù)據(jù)庫(kù)搞垮，每次請(qǐng)求的ID都是負(fù)數(shù)。這會(huì)導(dǎo)致我的緩存就沒(méi)用了，請(qǐng)求全部都找數(shù)據(jù)庫(kù)去了，但數(shù)據(jù)庫(kù)也沒(méi)有這個(gè)值啊，所以每次都返回空出去。

緩存穿透是指查詢(xún)一個(gè)一定不存在的數(shù)據(jù)。由于緩存不***，并且出于容錯(cuò)考慮，如果從數(shù)據(jù)庫(kù)查不到數(shù)據(jù)則不寫(xiě)入緩存，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到數(shù)據(jù)庫(kù)去查詢(xún)，失去了緩存的意義。

緩存穿透

這就是緩存穿透：

• 請(qǐng)求的數(shù)據(jù)在緩存大量不***，導(dǎo)致請(qǐng)求走數(shù)據(jù)庫(kù)。

緩存穿透如果發(fā)生了，也可能把我們的數(shù)據(jù)庫(kù)搞垮，導(dǎo)致整個(gè)服務(wù)癱瘓!

2.1 如何解決緩存穿透?

解決緩存穿透也有兩種方案：

• 由于請(qǐng)求的參數(shù)是不合法的(每次都請(qǐng)求不存在的參數(shù))，于是我們可以使用布隆過(guò)濾器(BloomFilter)或者壓縮filter提前攔截，不合法就不讓這個(gè)請(qǐng)求到數(shù)據(jù)庫(kù)層!

• 當(dāng)我們從數(shù)據(jù)庫(kù)找不到的時(shí)候，我們也將這個(gè)空對(duì)象設(shè)置到緩存里邊去。下次再請(qǐng)求的時(shí)候，就可以從緩存里邊獲取了。

• 這種情況我們一般會(huì)將空對(duì)象設(shè)置一個(gè)較短的過(guò)期時(shí)間。

參考資料：

• 緩存系列文章--5.緩存穿透問(wèn)題

https://carlosfu.iteye.com/blog/2248185

三、緩存與數(shù)據(jù)庫(kù)雙寫(xiě)一致

3.1 對(duì)于讀操作，流程是這樣的

上面講緩存穿透的時(shí)候也提到了：如果從數(shù)據(jù)庫(kù)查不到數(shù)據(jù)則不寫(xiě)入緩存。

一般我們對(duì)讀操作的時(shí)候有這么一個(gè)固定的套路：

• 如果我們的數(shù)據(jù)在緩存里邊有，那么就直接取緩存的。

• 如果緩存里沒(méi)有我們想要的數(shù)據(jù)，我們會(huì)先去查詢(xún)數(shù)據(jù)庫(kù)，然后將數(shù)據(jù)庫(kù)查出來(lái)的數(shù)據(jù)寫(xiě)到緩存中。

• ***將數(shù)據(jù)返回給請(qǐng)求

3.2 什么是緩存與數(shù)據(jù)庫(kù)雙寫(xiě)一致問(wèn)題?

如果僅僅查詢(xún)的話(huà)，緩存的數(shù)據(jù)和數(shù)據(jù)庫(kù)的數(shù)據(jù)是沒(méi)問(wèn)題的。但是，當(dāng)我們要更新時(shí)候呢?各種情況很可能就造成數(shù)據(jù)庫(kù)和緩存的數(shù)據(jù)不一致了。

• 這里不一致指的是：數(shù)據(jù)庫(kù)的數(shù)據(jù)跟緩存的數(shù)據(jù)不一致

數(shù)據(jù)庫(kù)和緩存的數(shù)據(jù)不一致

從理論上說(shuō)，只要我們?cè)O(shè)置了鍵的過(guò)期時(shí)間，我們就能保證緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)最終是一致的。因?yàn)橹灰彺鏀?shù)據(jù)過(guò)期了，就會(huì)被刪除。隨后讀的時(shí)候，因?yàn)榫彺胬餂](méi)有，就可以查數(shù)據(jù)庫(kù)的數(shù)據(jù)，然后將數(shù)據(jù)庫(kù)查出來(lái)的數(shù)據(jù)寫(xiě)入到緩存中。

除了設(shè)置過(guò)期時(shí)間，我們還需要做更多的措施來(lái)盡量避免數(shù)據(jù)庫(kù)與緩存處于不一致的情況發(fā)生。

3.3 對(duì)于更新操作

一般來(lái)說(shuō)，執(zhí)行更新操作時(shí)，我們會(huì)有兩種選擇：

• 先操作數(shù)據(jù)庫(kù)，再操作緩存

• 先操作緩存，再操作數(shù)據(jù)庫(kù)

首先，要明確的是，無(wú)論我們選擇哪個(gè)，我們都希望這兩個(gè)操作要么同時(shí)成功，要么同時(shí)失敗。所以，這會(huì)演變成一個(gè)分布式事務(wù)的問(wèn)題。

所以，如果原子性被破壞了，可能會(huì)有以下的情況：

• 操作數(shù)據(jù)庫(kù)成功了，操作緩存失敗了。

• 操作緩存成功了，操作數(shù)據(jù)庫(kù)失敗了。

如果***步已經(jīng)失敗了，我們直接返回Exception出去就好了，第二步根本不會(huì)執(zhí)行。

下面我們具體來(lái)分析一下吧。

3.3.1操作緩存操作緩存也有兩種方案：

• 更新緩存

• 刪除緩存

一般我們都是采取刪除緩存緩存策略的，原因如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 高并發(fā)環(huán)境下，無(wú)論是先操作數(shù)據(jù)庫(kù)還是后操作數(shù)據(jù)庫(kù)而言，如果加上更新緩存，那就更加容易導(dǎo)致數(shù)據(jù)庫(kù)與緩存數(shù)據(jù)不一致問(wèn)題。(刪除緩存直接和簡(jiǎn)單很多)

3. 如果每次更新了數(shù)據(jù)庫(kù)，都要更新緩存【這里指的是頻繁更新的場(chǎng)景，這會(huì)耗費(fèi)一定的性能】，倒不如直接刪除掉。等再次讀取時(shí)，緩存里沒(méi)有，那我到數(shù)據(jù)庫(kù)找，在數(shù)據(jù)庫(kù)找到再寫(xiě)到緩存里邊(體現(xiàn)懶加載)

基于這兩點(diǎn)，對(duì)于緩存在更新時(shí)而言，都是建議執(zhí)行刪除操作!

3.3.2先更新數(shù)據(jù)庫(kù)，再刪除緩存正常的情況是這樣的：

• 先操作數(shù)據(jù)庫(kù)，成功;

• 再刪除緩存，也成功;

如果原子性被破壞了：

• ***步成功(操作數(shù)據(jù)庫(kù))，第二步失敗(刪除緩存)，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)里是新數(shù)據(jù)，而緩存里是舊數(shù)據(jù)。

• 如果***步(操作數(shù)據(jù)庫(kù))就失敗了，我們可以直接返回錯(cuò)誤(Exception)，不會(huì)出現(xiàn)數(shù)據(jù)不一致。

如果在高并發(fā)的場(chǎng)景下，出現(xiàn)數(shù)據(jù)庫(kù)與緩存數(shù)據(jù)不一致的概率特別低，也不是沒(méi)有：

• 緩存剛好失效

• 線(xiàn)程A查詢(xún)數(shù)據(jù)庫(kù)，得一個(gè)舊值

• 線(xiàn)程B將新值寫(xiě)入數(shù)據(jù)庫(kù)

• 線(xiàn)程B刪除緩存

• 線(xiàn)程A將查到的舊值寫(xiě)入緩存

要達(dá)成上述情況，還是說(shuō)一句概率特別低：

因?yàn)檫@個(gè)條件需要發(fā)生在讀緩存時(shí)緩存失效，而且并發(fā)著有一個(gè)寫(xiě)操作。而實(shí)際上數(shù)據(jù)庫(kù)的寫(xiě)操作會(huì)比讀操作慢得多，而且還要鎖表，而讀操作必需在寫(xiě)操作前進(jìn)入數(shù)據(jù)庫(kù)操作，而又要晚于寫(xiě)操作更新緩存，所有的這些條件都具備的概率基本并不大。

對(duì)于這種策略，其實(shí)是一種設(shè)計(jì)模式：Cache Aside Pattern

先修改數(shù)據(jù)庫(kù)，再刪除緩存

刪除緩存失敗的解決思路：

• 將需要?jiǎng)h除的key發(fā)送到消息隊(duì)列中

• 自己消費(fèi)消息，獲得需要?jiǎng)h除的key

• 不斷重試刪除操作，直到成功

3.3.3先刪除緩存，再更新數(shù)據(jù)庫(kù)正常情況是這樣的：

• 先刪除緩存，成功;

• 再更新數(shù)據(jù)庫(kù)，也成功;

如果原子性被破壞了：

• ***步成功(刪除緩存)，第二步失敗(更新數(shù)據(jù)庫(kù))，數(shù)據(jù)庫(kù)和緩存的數(shù)據(jù)還是一致的。

• 如果***步(刪除緩存)就失敗了，我們可以直接返回錯(cuò)誤(Exception)，數(shù)據(jù)庫(kù)和緩存的數(shù)據(jù)還是一致的。

看起來(lái)是很美好，但是我們?cè)诓l(fā)場(chǎng)景下分析一下，就知道還是有問(wèn)題的了：

• 線(xiàn)程A刪除了緩存

• 線(xiàn)程B查詢(xún)，發(fā)現(xiàn)緩存已不存在

• 線(xiàn)程B去數(shù)據(jù)庫(kù)查詢(xún)得到舊值

• 線(xiàn)程B將舊值寫(xiě)入緩存

• 線(xiàn)程A將新值寫(xiě)入數(shù)據(jù)庫(kù)

所以也會(huì)導(dǎo)致數(shù)據(jù)庫(kù)和緩存不一致的問(wèn)題。

并發(fā)下解決數(shù)據(jù)庫(kù)與緩存不一致的思路：

• 將刪除緩存、修改數(shù)據(jù)庫(kù)、讀取緩存等的操作積壓到隊(duì)列里邊，實(shí)現(xiàn)串行化。

將操作積壓到隊(duì)列中

3.4對(duì)比兩種策略

我們可以發(fā)現(xiàn)，兩種策略各自有優(yōu)缺點(diǎn)：

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

• 在高并發(fā)下表現(xiàn)不如意，在原子性被破壞時(shí)表現(xiàn)優(yōu)異

• 先更新數(shù)據(jù)庫(kù)，再刪除緩存(Cache Aside Pattern設(shè)計(jì)模式)

• 在高并發(fā)下表現(xiàn)優(yōu)異，在原子性被破壞時(shí)表現(xiàn)不如意

3.5 其他保障數(shù)據(jù)一致的方案與資料

可以用databus或者阿里的canal監(jiān)聽(tīng)binlog進(jìn)行更新。

“Redis常見(jiàn)的面試題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！