聽說10個人去互聯網公司面試，有9個人會被問到緩存雪崩和緩存穿透的問題。 聽說，這9個人裡面，至少有8個人回答得不完整。 而這8個人裡面，全都是在網上找的各種面試資料去應付的，並沒有真正理解。 當然，也很正常，只有大規模應用緩存的架構才會重點關註這兩個問題。 那麼如何真正理解這兩個問題的底層邏輯，我 ...
聽說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學架構」公眾號公眾號獲取更多技術乾貨！
