一般來講，常見三大快取問題不外乎就是快取穿透、快取擊穿、快取雪崩。三者的共同點都是高併發，快取更新、快取失效居多。而且三者也會相互惡化，導致問題更加嚴重，因此一旦有一個問題就需要馬上解決，以免最終引起”雪崩”。本文將分別分析快取併發、快取雪崩、快取擊穿三大問題，並提出對應的解決方案。

一、快取穿透

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/nihao12323432/article/details/81205160