一般來講，常見三大緩存問題不外乎就是緩存穿透、緩存擊穿、緩存雪崩。三者的共同點都是高並發，緩存更新、緩存失效居多。而且三者也會相互惡化，導致問題更加嚴重，因此一旦有一個問題就需要馬上解決，以免最終引起”雪崩”。本文將分別分析緩存並發、緩存雪崩、緩存擊穿三大問題，並提出對應的解決方案。
一、緩存穿透
1、定義：正常情況下，我們去查詢數據都是存在。那么請求去查詢一條壓根兒數據庫中根本就不存在的數據，也就是緩存和數據庫都查詢不到這條數據，但是請求每次都會打到數據庫上面去。這種查詢不存在數據的現象我們稱為緩存穿透。
2、解決方案：
（1）存空值：之所以會發生穿透，就是因為緩存中沒有存儲這些空數據的key。從而導致每次查詢都到數據庫去了。那么我們就可以為這些key對應的值設置為null 丟到緩存里面去。后面再出現查詢這個key 的請求的時候，直接返回null 。這樣，就不用在到數據庫中去走一圈了，但是別忘了設置過期時間。
（2）BloomFilter：BloomFilter 類似於一個hbase set 用來判斷某個元素（key）是否存在於某個集合中。這種方式在大數據場景應用比較多，比如 Hbase 中使用它去判斷數據是否在磁盤上。還有在爬蟲場景判斷url 是否已經被爬取過。這種方案可以加在第一種方案中，在緩存之前在加一層 BloomFilter ，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查緩存 -> 查 DB。
二、緩存擊穿
1、定義：緩存擊穿是我們可能遇到的第二個使用緩存方案可能遇到的問題。在平常高並發的系統中，大量的請求同時查詢一個 key 時，此時這個key正好失效了，就會導致大量的請求都打到數據庫上面去。這種現象我們稱為緩存擊穿。
2、解決方案：上面的現象是多個線程同時去查詢數據庫的這條數據，那么我們可以在第一個查詢數據的請求上使用一個 互斥鎖來鎖住它。其他的線程走到這一步拿不到鎖就等着，等第一個線程查詢到了數據，然后做緩存。后面的線程進來發現已經有緩存了，就直接走緩存。
三、緩存雪崩
1、定義：緩存雪崩的情況是說，當某一時刻發生大規模的緩存失效的情況，比如你的緩存服務宕機了，會有大量的請求進來直接打到DB上面。結果就是DB 稱不住，掛掉。
2、解決方案：首先，使用集群緩存，保證緩存服務的高可用這種方案就是在發生雪崩前對緩存集群實現高可用，如果是使用 Redis，可以使用 主從+哨兵 ，Redis Cluster 來避免 Redis 全盤崩潰的情況。然后，ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時候，ehcache 本地緩存還能夠支撐一陣。使用 Hystrix進行限流 & 降級 ，比如一秒來了5000個請求，我們可以設置假設只能有一秒 2000個請求能通過這個組件，那么其他剩余的 3000 請求就會走限流邏輯。然后去調用我們自己開發的降級組件（降級），比如設置的一些默認值呀之類的。以此來保護最后的 MySQL 不會被大量的請求給打死。最后，開啟Redis持久化機制，盡快恢復緩存集群一旦重啟，就能從磁盤上自動加載數據恢復內存中的數據。
擴展知識
預熱
-
緩存預熱就是系統發布之前，先把緩存數據加載到系統里面，這樣避免了活動正式開始之前首次沒有命中，需要查詢數據庫的問題。
-
另外一方面預熱也是提前對流量的一種預估方式，很多大型活動或者秒殺，都會提前來一波預熱。
降級
-
當並發量很大的時候，響應慢或者超時，影響到核心業務處理（比如下單，支付），或者導致到上游的系統的系統扇出，這種情形下需要對服務進行降級，也就是丟車保帥的做法。
-
級，也就是丟車保帥的做法。
參考：https://www.boxuegu.com/news/1884.html
❤擴展：https://blog.csdn.net/lin777lin/article/details/105666839