阿里Java面試題剖析：了解什么是 redis 的雪崩和穿透？redis 崩潰之后會怎么樣？

面試原題

了解什么是 redis 的雪崩和穿透？redis 崩潰之后會怎么樣？系統(tǒng)該如何應對這種情況？如何處理 redis 的穿透？
面試官心理分析
其實這是問到緩存必問的，因為緩存雪崩和穿透，是緩存最大的兩個問題，要么不出現(xiàn)，一旦出現(xiàn)就是致命性的問題，所以面試官一定會問你。

面試題剖析

緩存雪崩
對于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個請求，本來緩存在高峰期可以扛住每秒 4000 個請求，但是緩存機器意外發(fā)生了全盤宕機。緩存掛了，此時 1 秒 5000 個請求全部落數(shù)據(jù)庫，數(shù)據(jù)庫必然扛不住，它會報一下警，然后就掛了。此時，如果沒用什么特別的方案來處理這個故障，DBA 很著急，重啟數(shù)據(jù)庫，但是數(shù)據(jù)庫立馬又被新的流量給打死了。

這就是緩存雪崩。

大約在 3 年前，國內(nèi)比較知名的一個互聯(lián)網(wǎng)公司，曾因為緩存事故，導致雪崩，后臺系統(tǒng)全部崩潰，事故從當天下午持續(xù)到晚上凌晨 3~4 點，公司損失了幾千萬。

緩存雪崩的事前事中事后的解決方案如下。

事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰。

事中：本地 ehcache 緩存 + hystrix 限流&降級，避免 MySQL 被打死。

事后：redis 持久化，一旦重啟，自動從磁盤上加載數(shù)據(jù)，快速恢復緩存數(shù)據(jù)。

用戶發(fā)送一個請求，系統(tǒng) A 收到請求后，先查本地 ehcache 緩存，如果沒查到再查 redis。如果 ehcache 和 redis 都沒有，再查數(shù)據(jù)庫，將數(shù)據(jù)庫中的結(jié)果，寫入 ehcache 和 redis 中。

限流組件，可以設(shè)置每秒的請求，有多少能通過組件，剩余的未通過的請求，怎么辦？走降級！可以返回一些默認的值，或者友情提示，或者空白的值。

好處：

數(shù)據(jù)庫絕對不會死，限流組件確保了每秒只有多少個請求能通過。

只要數(shù)據(jù)庫不死，就是說，對用戶來說，2/5 的請求都是可以被處理的。

只要有 2/5 的請求可以被處理，就意味著你的系統(tǒng)沒死，對用戶來說，可能就是點擊幾次刷不出來頁面，但是多點幾次，就可以刷出來一次。

緩存穿透
對于系統(tǒng)A，假設(shè)一秒 5000 個請求，結(jié)果其中 4000 個請求是發(fā)出的惡意。

發(fā)出的那 4000 個，緩存中查不到，每次你去數(shù)據(jù)庫里查，也查不到。

舉個栗子。數(shù)據(jù)庫 id 是從 1 開始的，結(jié)果發(fā)過來的請求 id 全部都是負數(shù)。這樣的話，緩存中不會有，請求每次都“視緩存于無物”，直接查詢數(shù)據(jù)庫。這種惡意場景的緩存穿透就會直接把數(shù)據(jù)庫給打死。

解決方式很簡單，每次系統(tǒng) A 從數(shù)據(jù)庫中只要沒查到，就寫一個空值到緩存里去，比如 set -999 UNKNOWN。這樣的話，下次便能走緩存了。

文末彩蛋：

針對于上面所涉及到的知識點我總結(jié)出了有1到5年開發(fā)經(jīng)驗的程序員在面試中涉及到的絕大部分架構(gòu)面試題及答案做成了文檔和架構(gòu)視頻資料免費分享給大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并發(fā)等架構(gòu)技術(shù)資料），希望能幫助到您面試前的復習且找到一個好的工作，也節(jié)省大家在網(wǎng)上搜索資料的時間來學習，也可以關(guān)注我一下以后會有更多干貨分享。

資料獲取方式 QQ群搜索“708-701-457” 備注“51CTO” 即可免費領(lǐng)取