[[403821]]

本文轉(zhuǎn)載自微信公眾號(hào)「大魚仙人」，作者大魚。轉(zhuǎn)載本文請(qǐng)聯(lián)系大魚仙人公眾號(hào)。

眼光不錯(cuò)，小伙子，看到這篇文章了就血賺，這篇文章絕對(duì)讓你學(xué)到開心，這是面試的殺器，其實(shí)Redis這個(gè)東西吧，我個(gè)人認(rèn)為，真的真的很強(qiáng)大，但是呢，又感覺被吹得有點(diǎn)過頭了

不過人家也確實(shí)有這個(gè)資本，人家性能強(qiáng)大，使用操作也很簡(jiǎn)單，有提供了各種持久化手段來解決斷電丟失的問題，而且人家讀寫速度都是大幾萬每秒，甚至十幾萬的速度，性能強(qiáng)大而且使用簡(jiǎn)單，所以絕大多數(shù)的公司都會(huì)使用Redis

于是乎，Redis的面試的優(yōu)先級(jí)也是被大大的提高了，而Redis中的經(jīng)典的緩存的各種問題，也是成為了程序員的必備技能之一

緩存雪崩、緩存穿透和緩存擊穿都是屬于比較典型的問題，當(dāng)然這篇文章就是為了給大家解釋清楚這三者到底是怎么回事，還有一般情況下如何來解決相應(yīng)的問題，當(dāng)然這篇也沒有什么很特殊的厲害的法子，相應(yīng)的法子估計(jì)百度也是一大堆

不過呢，相見既緣分，你看到這篇文章了，我當(dāng)然要給親愛的大家準(zhǔn)備一篇最齊全的解決法子咯，幫助大家真正的了解并學(xué)會(huì)解決這些問題

緩存雪崩

不過呢，相見既緣分，你看到這篇文章了，我當(dāng)然要給親愛的大家準(zhǔn)備一篇最齊全的解決法子咯，幫助大家真正的了解并學(xué)會(huì)解決這些問題

雪崩，這個(gè)詞聽著就很糟糕，可能很多人已經(jīng)猜到了個(gè)大概了，這指的就是大面積的緩存集體失效

舉個(gè)典型的例子，在寫入本文的時(shí)候，比如馬上到618的時(shí)候，就會(huì)很快迎來了一波大促銷，大搶購，就是因?yàn)樵L問量特別的高，所以要把這些商品都放在緩存中提高效率，假設(shè)這一個(gè)頁面的數(shù)據(jù)都緩存了一個(gè)小時(shí)，那么到了凌晨一點(diǎn)鐘的時(shí)候，這些商品的緩存就都會(huì)過期了，而對(duì)這批商品的訪問，就都落在了DB上，這樣DB就會(huì)很容易崩潰

當(dāng)一點(diǎn)的時(shí)候每秒八千個(gè)請(qǐng)求，本來緩存可以挺住五千每秒的請(qǐng)求，但是當(dāng)緩存突然失效的時(shí)候，這每秒八千的請(qǐng)求直接全都打在DB上，數(shù)據(jù)庫直接就扛不住了，沒準(zhǔn)直接就掛了，此時(shí)如果沒用什么特別的方案來處理這個(gè)故障，DBA也容易崩潰，重啟數(shù)據(jù)庫，但是會(huì)立即被下面的流量打崩

這就是我個(gè)人理解的緩存雪崩

同一時(shí)間的緩存大面試失效，對(duì)于線上的情況來說，應(yīng)該會(huì)是一個(gè)災(zāi)難，如果你這么做了，恭喜你，埋下了一個(gè)大雷，你想想啊，如果DB直接崩了，那意味著用戶可能要開始***了，這個(gè)時(shí)候用戶都是熬夜熬了很久等著購買自己心愛的產(chǎn)品呢，結(jié)果你軟件崩了，啥也買不了了

什么，連我辛苦好幾天搶的券都不能用了，什么破軟件，卸載，再也不用了，如果真出現(xiàn)這樣的場(chǎng)景，收拾東西吧

說的不錯(cuò)，這是個(gè)大問題，那一般這種情況該如何處理呢，你都是如何應(yīng)對(duì)的

其實(shí)處理這個(gè)也很簡(jiǎn)單了，在批量的往Redis中放置數(shù)據(jù)的時(shí)候，把每個(gè)key的失效時(shí)間都加個(gè)相應(yīng)的隨機(jī)值即可

這樣就可以避免大面積的緩存數(shù)據(jù)在同一時(shí)間失效這個(gè)問題，公司一般使用Redis都是集群部署的，這樣將熱點(diǎn)數(shù)據(jù)均勻分布在不同的Redis庫中也可以避免全部失效的問題，失效時(shí)間設(shè)為隨機(jī)有時(shí)候也是一種不錯(cuò)的策略

或者設(shè)置熱點(diǎn)數(shù)據(jù)永遠(yuǎn)不過期，有更新操作就直接更新緩存就好了，看到數(shù)據(jù)A的緩存過期了，再重新緩存下，數(shù)據(jù)B的緩存過期了，再重新緩存下B，這樣也可以刷下緩存就好了

緩存穿透和緩存擊穿

我們先來說下緩存穿透，緩存穿透指的是緩存和數(shù)據(jù)庫都沒有的數(shù)據(jù)，然而用戶卻不斷的發(fā)起請(qǐng)求，這樣的很可能是就是屬于惡意請(qǐng)求

舉個(gè)例子，我們數(shù)據(jù)庫的ID都是自增上去的，如果發(fā)起者的ID為-1的情況，或者ID不存在的特別大的情況，這時(shí)候的用戶很可能是攻擊者，造成數(shù)據(jù)庫的攻擊壓力會(huì)變得很大，嚴(yán)重的可能會(huì)導(dǎo)致直接打崩DB

其實(shí)這種情況，程序員一般會(huì)對(duì)這種惡意情況進(jìn)行過濾，但是萬一有漏洞呢，萬一有程序員忘記了對(duì)參數(shù)進(jìn)行校驗(yàn)，這種情況如果一直用小于0的參數(shù)去請(qǐng)求你，每次都能繞開Redis直接打到DB，數(shù)據(jù)庫查不到，每次都這樣，并發(fā)高點(diǎn)可能就會(huì)容易搞崩，一些小的單機(jī)系統(tǒng)，基本上用postman可能就能打崩

至于緩存擊穿嗎，這個(gè)和緩存雪崩有點(diǎn)像，但是肯定也是有不一樣的地方，緩存雪崩是因?yàn)榇竺娣e的緩存失效，打崩了DB，而緩存擊穿不同的是緩存擊穿指的是一個(gè)Key非常熱點(diǎn)，比如之前的某爽這種事情，占用公共資源的眼球，人們都去噴，此時(shí)這個(gè)Key就是一個(gè)大熱點(diǎn)，在不停的扛著大并發(fā)，大并發(fā)集中的對(duì)這一個(gè)點(diǎn)進(jìn)行訪問，當(dāng)這個(gè)key在失效的那一瞬間，也就是某爽的這個(gè)key突然失效了，持續(xù)的大并發(fā)就會(huì)直接穿破緩存，直接將請(qǐng)求打到DB，就像是在一個(gè)完好無損的桶上鑿開了一個(gè)洞

那該如何解決呢，緩存穿透和擊穿這兩種情況

緩存穿透嗎，這個(gè)是程序員必須要做的防備之一，接口層的校驗(yàn)，比如參數(shù)的校驗(yàn)、用戶的鑒權(quán)行為這種，對(duì)于那些不合法的請(qǐng)求直接return或者報(bào)錯(cuò)就好了

我們?cè)陂_發(fā)的時(shí)候，不僅要把用戶的行為各種猜測(cè)，我們還要做的是提防各種惡意請(qǐng)求，我們要對(duì)程序的各個(gè)接口有一顆不信任的心，這個(gè)不信任指的是對(duì)于參數(shù)的各種情況、對(duì)于用戶行為的多方面考慮，因?yàn)槟悴荒艽_定來的請(qǐng)求一定是正常的，不能保證調(diào)用方一定是正常的調(diào)用方，所以一定要對(duì)那些非正常的調(diào)用方進(jìn)行一定的校驗(yàn)和處理

緩存穿透這種需要在代碼中根據(jù)業(yè)務(wù)的實(shí)際情況來做出相應(yīng)的控制，對(duì)不符合條件的請(qǐng)求做出相應(yīng)的過濾，這應(yīng)該屬于做基本的要求之一，如果這種情況真出現(xiàn)在生產(chǎn)上，那肯定屬于T1級(jí)別的重大Bug了

我們常用的法子就是先從緩存中取數(shù)據(jù)，如果緩存中取不到就直接通過數(shù)據(jù)庫來取數(shù)據(jù)，如果取不到，我們可以將key和value都是null寫入到緩存中，設(shè)置一定的時(shí)間，可以有效的防止惡意用戶反復(fù)用同一個(gè)ID來暴力攻擊，其實(shí)我們也可以在網(wǎng)關(guān)層做出相應(yīng)的控制，因?yàn)橛脩舨豢赡茉诙虝r(shí)間內(nèi)做出大量的多次請(qǐng)求的，當(dāng)出現(xiàn)非正常頻率的請(qǐng)求的IP或者機(jī)器的時(shí)候，可以對(duì)這些IP和機(jī)器進(jìn)行限制

緩存擊穿這種問題，其實(shí)最簡(jiǎn)單的辦法就是設(shè)置緩存永不過期就好了，這應(yīng)該是最簡(jiǎn)單粗暴的方法了，或者通過互斥鎖也是可以解決這種

布隆過濾器

在redis中其實(shí)還有一個(gè)高級(jí)點(diǎn)的用法，布隆過濾器Bloom Filter，這個(gè)也可以很好的防止緩存穿透的發(fā)生，可以說這個(gè)就是為了防止這種情況而出生，利用極小的空間可以表示出大量的數(shù)據(jù)是否存在，但是這個(gè)是有一定的缺點(diǎn)的，缺點(diǎn)就是會(huì)存在一定的誤判率

布隆過濾器可以利用其高效的數(shù)據(jù)結(jié)構(gòu)和算法快速的判斷出你操作的這個(gè)key在數(shù)據(jù)庫中是否存在，不存在直接return就好了，也就不用達(dá)到DB了，這樣就可以很好的避免緩存穿透的問題

即使很多IP同時(shí)發(fā)起攻擊，其實(shí)正常的redis集群也是頂?shù)米〉?，小公司一般用的也是小的redis集群，不過一般他們也不感興趣對(duì)這些公司

簡(jiǎn)單說下布隆過濾器的原理吧

布隆過濾器，首先想的是啥，你肯定想到的是為啥叫這個(gè)名字，玩過lol的小伙伴，肯定第一時(shí)間腦海里冒出來的是這個(gè)吧

圖片

經(jīng)常玩輔助位置的小伙伴更是喜聞樂見，看見了這個(gè)春心開始蕩漾了，于是忍不住打開了桌面的lol，點(diǎn)擊了play，打完一把感覺隊(duì)友很氣，于是又開了一把...

好了好了，玩笑歸玩笑，來理解下這個(gè)布隆過濾器吧，我這里只是粗略的說一下原理，不詳細(xì)的解釋

布隆過濾器：一個(gè)很大的bit數(shù)組組成，系統(tǒng)在初始化的時(shí)候，會(huì)把數(shù)據(jù)庫已經(jīng)存在的商品的ID通過哈希再映射到bit數(shù)組的位置上，最后便可以通過數(shù)組上相應(yīng)的位置的值是否正確即可判斷是否存在商品

這樣說，可能有些晦澀

舉個(gè)例子：現(xiàn)在有一個(gè)很大的bit位數(shù)組，初始化全部位置為0

數(shù)據(jù)庫中存在商品1、2、3，然后我們有16個(gè)哈希函數(shù)，把1經(jīng)過16個(gè)哈希函數(shù)映射得到16個(gè)哈希值，這16個(gè)哈希值會(huì)對(duì)應(yīng)bit數(shù)組的16個(gè)位置，置為1;同樣的操作對(duì)2、3，也都會(huì)產(chǎn)生16個(gè)哈希值，也就是對(duì)應(yīng)32個(gè)哈希位置，也都置為1;

最后會(huì)最多產(chǎn)生48個(gè)位置，為什么說是最多呢，因?yàn)?、2、3的映射可能會(huì)映射到同一個(gè)位置，所以說最極限的情況就是會(huì)產(chǎn)生48個(gè)位置的1

此時(shí)如果惡意請(qǐng)求攜帶商品為-1的請(qǐng)求打過來，也會(huì)對(duì)-1進(jìn)行相應(yīng)的操作，于是得到16個(gè)哈希值，對(duì)應(yīng)bit數(shù)組中的16個(gè)位置，我們可以通過判斷這16個(gè)位置是否全是1來判斷數(shù)據(jù)庫中是否存在-1這個(gè)商品

你可能也看出來了，這樣會(huì)存在一定的誤判率，也就是存在一種極限情況，1、2、3產(chǎn)生的所有位置的映射值已經(jīng)將-1的16個(gè)位置全部置為1了，當(dāng)然這種情況也是比較少見的

一句話概述：有0一定不存在，但是全部為1，并不一定存在，所以存在一定的誤判率

不錯(cuò)啊，小伙子，經(jīng)過這么多輪的盤問，看來你對(duì)redis掌握的還可以

謝謝面試官的夸獎(jiǎng)，請(qǐng)問offer什么時(shí)候能發(fā)到我的email里呢，畢竟我已經(jīng)快一個(gè)多月沒有上班，沒有工資了，對(duì)于打工人來說，沒有工資是很難辦的

而且我這副業(yè)也還在起步階段，還在慢慢的寫，如果大家都能給個(gè)點(diǎn)贊給個(gè)關(guān)注，我也可以靠這個(gè)來恰點(diǎn)飯，這樣也不用這么著急要offer，也可以多面試幾輪，多給大家扯扯淡了(瘋狂暗示)

懂了，接下來我再問問你的設(shè)計(jì)模式這塊，就差不多了，因?yàn)槲覀児緦?duì)設(shè)計(jì)編碼這塊要求比較高，所以需要考察考察你的編碼設(shè)計(jì)能力

好嘞，沒問題，多謝面試官給透漏下一次的面試重點(diǎn)，我回去也好好準(zhǔn)備準(zhǔn)備

強(qiáng)行暗示下一系列

總結(jié)

其實(shí)這些問題算是類似的問題，也算是比較常見的問題，不要把這三個(gè)搞混了，這些問題應(yīng)該是面試的香餑餑了，很多面試官都會(huì)問，即使不問，如果你能引出這些，并且給面試官講解請(qǐng)求，那面試官對(duì)你的好感也會(huì)大大增加

我們對(duì)于redis一般就是從三個(gè)時(shí)間段來解決各種問題的：

1、Redis高可用，哨兵、主從架構(gòu)、集群，避免全盤直接崩潰的那種，這種主要是避免災(zāi)難性的事故

2、過程中，本地ehcache緩存，Hystrix限流和降級(jí)來解決高流量，避免大流量直接打崩DB

3、之后的redis持久化：RDB和AOF，重啟自動(dòng)加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)，合理的配置可以做到幾乎零丟失數(shù)據(jù)