關於緩存穿透，緩存擊穿，緩存雪崩，熱點數據失效問題的解決方案

1.我們使用緩存時的業務流程大概為：

當我們查詢一條數據時，先去查詢緩存，如果緩存有就直接返回，如果沒有就去查詢資料庫，然後返回。這種情況下就可能出現下麵的一些現象。

2.緩存穿透

2.1什麼是緩存穿透

緩存穿透是指查詢一個一定不存在的數據，由於緩存是不命中時被動寫的，並且出於容錯考慮，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。

2.2緩存穿透帶來的問題

試想一下，如果有黑客對你的系統進行攻擊，拿一個不存在的id去查詢數據，會產生大量的請求到你的資料庫去查詢，可能會導致你的資料庫由於壓力過大而宕掉。

2.3解決的辦法

2.3.1緩存空值

之所以會發生穿透，就是因為緩存中沒有儲存這些空數據的key。從而導致每次查詢都到資料庫去了。

那麼我們就可以為這些key對應的值設置為null丟到緩存裡面去。後面出現查詢這個key的請求的時候直接返回null。

這樣就不用再到資料庫中去走一圈了，但是別忘了設置過期時間。

緩存空對象會有兩個問題：

 第一，空值做了緩存，意味著緩存層中存了更多的鍵，需要更多的記憶體空間 ( 如果是攻擊，問題更嚴重 )，比較有效的方法是針對這類數據設置一個較短的過期時間，讓其自動剔除。

 第二，緩存層和存儲層的數據會有一段時間視窗的不一致，可能會對業務有一定影響。例如過期時間設置為 5分鐘，如果此時存儲層添加了這個數據，那此段時間就會出現緩存層和存儲層數據的不一致，此時可以利用消息系統或者其他方式清除掉緩存層中的空對象。

2.3.2用布隆過濾器BloomFilter

BloomFilter類似於一個hbase set用來判斷某個元素(key)是否存在於某個集合中。

這種方式在大數據場景應用比較多，比如Hbase中使用它去判斷數據是否在磁碟上。還有在爬蟲場景判斷url是否已經被爬取過。

這種方案可以加在第一種方案中，在緩存之前加一層BloomFilter，在查詢的時候先去BloomFilter去查詢key是否存在，如果不存在就直接返回，存在再去查緩存-------->差資料庫。

流程圖如下：

2.4如何選擇

針對於一些惡意攻擊，攻擊帶來大量key是不存在的，那麼我們採用第一種方案就會緩存大量不存在的數據。此時我們採用第一種方案就不合適了，我們完全可以先使用第二種方案過濾掉這些key。

針對這些key異常多，請求多，重覆率比較低的數據，我們就沒有必要進行緩存，使用第二種方案直接過濾掉。

而對於空數據的key有限的，重覆率比較高的，我們則可以採用第一種方式進行緩存。

3.緩存擊穿

3.1什麼是緩存擊穿

緩存擊穿是我們使用緩存可能遇到的第二個問題。

在平時高併發的系統中，大量的請求同時查詢一個key時，此時這個key正好失效了，就會導致大量的請求都打到資料庫上面去，這種現象我們稱為緩存擊穿。

3.2會帶來什麼問題

會造成某一時刻數據請求量過大，壓力劇增。

3.3如何解決

上面現象是多個線程同時去查詢資料庫的這一條數據，那麼我們可以在第一個查詢數據的請求上使用一個互斥鎖來鎖住它。（如果是單機，可以用synchronized或者lock來處理，如果是分散式環境可以用分散式鎖就可以了（分散式鎖，可以用memcache的add, redis的setnx, zookeeper的添加節點操作））

其他線程走到這一步拿不到鎖就等著，等待第一個線程查詢到了數據，然後做緩存。後面的線程進來發現已經有了緩存，就直接走緩存。

4.緩存雪崩

 4.1什麼是緩存雪崩

緩存雪崩的情況是指：當某一時刻發生大規模的緩存失效的情況，比如你的緩存服務宕機了，會有大量的請求進來直接打到資料庫上面，結果就是資料庫掛掉。

4.2解決辦法

4.2.1雪崩前：使用集群緩存，保證緩存服務的高可用

這種方案就是在發生雪崩前對緩存集群，實現高可用，如果是使用Redis，可以使用（主從  +  哨兵），Redis Cluster來避免Redis全盤崩潰的情況。

4.2.2雪崩中：ehcache本地緩存  +  Hystrix限流  &  降級，避免MySQl被打死

使用ehcache本地緩存的目的也是考慮Redis Cluster完全不可用的時候，ehcache本地緩存還能夠支撐一陣。

使用Hystrix進行限流 & 降級，比如一秒來了5000個請求，我們可以設置假設一秒只能有2000個請求可以通過這個組件，那麼其他剩餘的3000請求就會走限流邏輯。

然後去調用我們自己開發的降級組件（降級）,比如設置的一些預設值等等之類的。以此來保護最後的MySQl不會被大量的請求打死。

4.2.3雪崩後：開啟Redis持久化，儘快恢復緩存集群。

5.解決熱點數據集中失效問題

我們在設置緩存的時候，一般會給緩存設置一個失效的時間，過了這個時間，緩存就失效了。

對於一些熱點數據來說，當緩存失效後會存在大量的請求到資料庫上來，從而可能導致資料庫崩潰的情況。

5.1解決辦法

5.1.1設置不同的失效時間

為了避免這些熱點數據集體失效，那麼我們在設置緩存過期時間的時侯，讓他們失效的時間錯開。比如我們可以在原有的失效時間基礎上增加一個隨機值。

5..1.2互斥鎖

結合上面的擊穿情況，在第一個請求去查詢資料庫的時候對它加一個互斥鎖，其餘的查詢請求都會被阻塞住，直到鎖被釋放，從而保護資料庫。

但是也是由於它會阻塞其他線程，此時系統的吞吐量會下降。需要結合實際業務去考慮。

 參考：

https://www.cnblogs.com/hadley/p/9535313.html

http://www.imooc.com/article/283986

當我們查詢一條數據時，先去查詢緩存，如果緩存有就直接返回，如果沒有就去查詢資料庫，然後返回。這種情況下就可能會出現一些現象。