【面試普通人VS高手系列】說說緩存雪崩和緩存穿透的理解，以及如何避免？

2022 年 5 月 5 日
筆記

聽說10個人去互聯網公司面試，有9個人會被問到緩存雪崩和緩存穿透的問題。

聽說，這9個人裏面，至少有8個人回答得不完整。

而這8個人裏面，全都是在網上找的各種面試資料去應付的，並沒有真正理解。

當然，也很正常，只有大規模應用緩存的架構才會重點關注這兩個問題。

那麼如何真正理解這兩個問題的底層邏輯，我們來看普通人和高手的回答。

普通人：

嗯……………..

高手：

緩存雪崩，就是存儲在緩存裏面的大量數據，在同一個時刻全部過期，

原本緩存組件抗住的大部分流量全部請求到了數據庫。

導致數據庫壓力增加造成數據庫服務器崩潰的現象。

導致緩存雪崩的主要原因，我認為有兩個：

緩存中間件宕機，當然可以對緩存中間件做高可用集群來避免。
緩存中大部分key都設置了相同的過期時間，導致同一時刻這些key都過期了。對於這樣的情況，可以在失效時間上增加一個1到5分鐘的隨機值。

緩存穿透問題，表示是短時間內有大量的不存在的key請求到應用裏面，而這些不存在的key在緩存裏面又找不到，從而全部穿透到了數據庫，造成數據庫壓力。

我認為這個場景的核心問題是針對緩存的一種攻擊行為，因為在正常的業務裏面，即便是出現了這樣的情況，由於緩存的不斷預熱，影響不會很大。

而攻擊行為就需要具備時間是的持續性，而只有key確實在數據庫裏面也不存在的情況下，才能達到這個目的，所以，我認為有兩個方法可以解決：

把無效的key也保存到Redis裏面，並且設置一個特殊的值，比如「null」，這樣的話下次再來訪問，就不會去查數據庫了。
但是如果攻擊者不斷用隨機的不存在的key來訪問，也還是會存在問題，所以可以用布隆過濾器來實現，在系統啟動的時候把目標數據全部緩存到布隆過濾器裏面，當攻擊者用不存在的key來請求的時候，先到布隆過濾器裏面查詢，如果不存在，那意味着這個key在數據庫裏面也不存在。

布隆過濾器還有一個好處，就是它採用了bitmap來進行數據存儲，佔用的內存空間很少。

不過，在我看來，您提出來的這個問題，有點過於放大了它帶來的影響。

首先，在一個成熟的系統裏面，對於比較重要的熱點數據，必然會有一個專門緩存系統來維護，同時它的過期時間的維護必然和其他業務的key會有一定的差別。而且非常重要的場景，我們還會設計多級緩存系統。

其次，即便是觸發了緩存雪崩，數據庫本身的容災能力也並沒有那麼脆弱，數據庫的主從、雙主、讀寫分離這些策略都能夠很好的緩解並發流量。

最後，數據庫本身也有最大連接數的限制，超過限制的請求會被拒絕，再結合熔斷機制，也能夠很好的保護數據庫系統，最多就是造成部分用戶體驗不好。

另外，在程序設計上，為了避免緩存未命中導致大量請求穿透到數據庫的問題，還可以在訪問數據庫這個環節加鎖。雖然影響了性能，但是對系統是安全的。

總而言之，我認為解決的辦法很多，具體選擇哪種方式，還是看具體的業務場景。

以上就是我對這個問題的理解。

總結

我發現現在很多面試，真的是為了面試而面試，要麼就是在網上摘題，要麼就是不斷的問一些無關痛癢的問題。

至於最終面試官怎麼判斷你是否合適，咱也不知道，估計就是有些小夥伴說的，看長相，看眼緣！

我認為一個合格的面試官，他必須要具備非常深厚的技術功底。

本期的普通人VS高手面試系列就到這裡結束了，喜歡的朋友記得點贊和收藏。

另外，有任何技術上的問題，職業發展有關的問題，都可以私信我，我會在第一時間回復。

版權聲明：本博客所有文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自 Mic帶你學架構！
如果本篇文章對您有幫助，還請幫忙點個關注和贊，您的堅持是我不斷創作的動力。歡迎關注「跟着Mic學架構」公眾號公眾號獲取更多技術乾貨！