阿里面試Redis最常問的三個問題：快取雪崩、擊穿、穿透（帶答案）

阿里面試Redis最常問的三個問題：快取雪崩、擊穿、穿透（帶答案）

好文章好文章，獲益匪淺，阿里內部面試題，真是大開眼界，迫不及待拿來與大家分享，原文來自“ 敖丙 ”，喜歡請支持原作者，感謝！

開門見山，面試官：小伙子我看你的簡歷上寫到了Redis，那么我們直接開門見山，直接懟常見的幾個大問題，Redis雪崩了解么？

帥氣迷人的面試官您好，我了解的，目前電商首頁以及熱點資料都會去做快取 ，一般快取都是定時任務去重繪，或者是查不到之后去更新的，定時任務重繪就有一個問題，

舉個簡單的例子：

如果所有首頁的Key失效時間都是12小時，中午12點重繪的，我零點有個秒殺活動大量用戶涌入，假設當時每秒 6000 個請求，本來快取在可以扛住每秒 5000 個請求，但是快取當時所有的Key都失效了，此時 1 秒 6000 個請求全部落資料庫，資料庫必然扛不住，它會報一下警，真實情況可能DBA都沒反應過來就直接掛了，此時，如果沒用什么特別的方案來處理這個故障，DBA 很著急，重啟資料庫，但是資料庫立馬又被新的流量給打死了，這就是我理解的快取雪崩，

我刻意看了下我做過的專案感覺再吊的都不允許這么大的QPS直接打DB去，不過沒慢SQL加上分庫，大表分表可能還還算能頂，但是跟用了Redis的差距還是很大，

同一時間大面積失效，那一瞬間Redis跟沒有一樣，那這個數量級別的請求直接打到資料庫幾乎是災難性的，你想想如果打掛的是一個用戶服務的庫，那其他依賴他的庫所有的介面幾乎都會報錯，如果沒做熔斷等策略基本上就是瞬間掛一片的節奏，你怎么重啟用戶都會把你打掛，等你能重啟的時候，用戶早就睡覺去了，并且對你的產品失去了信心，什么垃圾產品，

面試官摸了摸自己的頭發，嗯還不錯，那這種情況咋整？你都是怎么去應對的？

處理快取雪崩簡單，在批量往Redis存資料的時候，把每個Key的失效時間都加個隨機值就好了，這樣可以保證資料不會在同一時間大面積失效，我相信，Redis這點流量還是頂得住的，

setRedis（Key，value，time + Math.random() * 10000）；

如果Redis是集群部署，將熱點資料均勻分布在不同的Redis庫中也能避免全部失效的問題，不過本渣我在生產環境中操作集群的時候，單個服務都是對應的單個Redis分片，是為了方便資料的管理，但是也同樣有了可能會失效這樣的弊端，失效時間隨機是個好策略，

或者設定熱點資料永遠不過期，有更新操作就更新快取就好了（比如運維更新了首頁商品，那你刷下快取就完事了，不要設定過期時間），電商首頁的資料也可以用這個操作，保險，

那你了解快取穿透和擊穿么，可以說說他們跟雪崩的區別么？

嗯，了解，我先說一下快取穿透吧，快取穿透是指快取和資料庫中都沒有的資料，而用戶不斷發起請求，我們資料庫的 id 都是1開始自增上去的，如發起為id值為 -1 的資料或 id 為特別大不存在的資料，這時的用戶很可能是攻擊者，攻擊會導致資料庫壓力過大，嚴重會擊垮資料庫，

小點的單機系統，基本上用postman就能搞死，比如我自己買的阿里云服務，

像這種你如果不對引數做校驗，資料庫id都是大于0的，我一直用小于0的引數去請求你，每次都能繞開Redis直接打到資料庫，資料庫也查不到，每次都這樣，并發高點就容易崩掉了，

至于快取擊穿，這個跟快取雪崩有點像，但是又有一點不一樣，快取雪崩是因為大面積的快取失效，打崩了DB，而快取擊穿不同的是快取擊穿是指一個Key非常熱點，在不停的扛著大并發，大并發集中對這一個點進行訪問，當這個Key在失效的瞬間，持續的大并發就穿破快取，直接請求資料庫，就像在一個完好無損的桶上鑿開了一個洞，

面試官露出欣慰的眼光，那他們分別怎么解決

快取穿透我會在介面層增加校驗，比如用戶鑒權校驗，引數做校驗，不合法的引數直接代碼Return，比如：id 做基礎校驗，id <=0的直接攔截等，

這里我想提的一點就是，我們在開發程式的時候都要有一顆“不信任”的心，就是不要相信任何呼叫方，比如你提供了API介面出去，你有這幾個引數，那我覺得作為被呼叫方，任何可能的引數情況都應該被考慮到，做校驗，因為你不相信呼叫你的人，你不知道他會傳什么引數給你，

舉個簡單的例子，你這個介面是分頁查詢的，但是你沒對分頁引數的大小做限制，呼叫的人萬一一口氣查 Integer.MAX_VALUE 一次請求就要你幾秒，多幾個并發你不就掛了么？是公司同事呼叫還好大不了發現了改掉，但是如果是黑客或者競爭對手呢？在你雙十一當天就調你這個介面會發生什么，就不用我說了吧，這是之前的Leader跟我說的，我覺得大家也都應該了解下，

從快取取不到的資料，在資料庫中也沒有取到，這時也可以將對應Key的Value對寫為null、位置錯誤、稍后重試這樣的值具體取啥問產品，或者看具體的場景，快取有效時間可以設定短點，如30秒（設定太長會導致正常情況也沒法使用），

這樣可以防止攻擊用戶反復用同一個id暴力攻擊，但是我們要知道正常用戶是不會在單秒內發起這么多次請求的，那網關層Nginx本渣我也記得有配置項，可以讓運維大大對單個IP每秒訪問次數超出閾值的IP都拉黑，

那你還有別的辦法么？

還有我記得Redis還有一個高級用法布隆過濾器（Bloom Filter）這個也能很好的防止快取穿透的發生，他的原理也很簡單就是利用高效的資料結構和演算法快速判斷出你這個Key是否在資料庫中存在，不存在你return就好了，存在你就去查了DB重繪KV再return，

那又有小伙伴說了如果黑客有很多個IP同時發起攻擊呢？這點我一直也不是很想得通，但是一般級別的黑客沒這么多肉雞，再者正常級別的Redis集群都能抗住這種級別的訪問的，小公司我想他們不會感興趣的，把系統的高可用做好了，集群還是很能頂的，

快取擊穿的話，設定熱點資料永遠不過期，或者加上互斥鎖就能搞定了

作為暖男，代碼我肯定幫你們準備好了

嗯嗯還不錯，三個點都回答得很好，今天也不早了，面試就先到這里，明天你再過來二面我繼續問一下你關于Redis集群高可用，主從同步，哨兵等知識點的問題，

我們玩歸玩，鬧歸鬧，別拿面試開玩笑，

本文簡單的介紹了，Redis的雪崩，擊穿，穿透，三者其實都差不多，但是又有一些區別，在面試中其實這是問到快取必問的，大家不要把三者搞混了，因為快取雪崩、穿透和擊穿，是快取最大的問題，要么不出現，一旦出現就是致命性的問題，所以面試官一定會問你，

大家一定要理解是怎么發生的，以及是怎么去避免的，發生之后又怎么去搶救，你可以不是知道很深入，但是你不能一點都不去想，面試有時候不一定是對知識面的拷問，或許是對你的態度的拷問，如果你思路清晰，然后知其然還知其所以然那就很贊，還知道怎么預防那來上班吧，

最后暖男我繼續給你們做個小的技術總結：

一般避免以上情況發生我們從三個時間段去分析下：

1. 事前：Redis 高可用，主從+哨兵，Redis cluster，避免全盤崩潰，
2. 事中：本地 ehcache 快取 + Hystrix 限流+降級，避免MySQL 被打死，
3. 事后：Redis 持久化 RDB+AOF，一旦重啟，自動從磁盤上加載資料，快速恢復快取資料，
   

上面的幾點我會在吊打系列Redis篇全部講一下這個月應該可以吧Redis更完，限流組件，可以設定每秒的請求，有多少能通過組件，剩余的未通過的請求，怎么辦？走降級！可以回傳一些默認的值，或者友情提示，或者空白的值，

好處

資料庫絕對不會死，限流組件確保了每秒只有多少個請求能通過， 只要資料庫不死，就是說，對用戶來說，3/5 的請求都是可以被處理的， 只要有 3/5 的請求可以被處理，就意味著你的系統沒死，對用戶來說，可能就是點擊幾次刷不出來頁面，但是多點幾次，就可以刷出來一次，

這個在目前主流的互聯網大廠里面是最常見的，你是不是好奇，某明星爆出什么事情，你發現你去微博怎么刷都空白界面，但是有的人又直接進了，你多刷幾次也出來了，現在知道了吧，那是做了降級，犧牲部分用戶的體驗換來服務器的安全，可還行？

你知道的越多，你不知道的越多，人才們的 【三連】 就是丙丙創作的最大動力，我們下期見！

推薦閱讀：

Canvas悟空推箱子
JS貪吃蛇
5分鐘學會Vue路由守衛
JS激流勇進附地圖詳解
什么是磁盤列陣技術