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

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互斥鎖

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

可是也是因爲它會阻塞其餘線程，此時系統的吞吐量會降低。須要結合實際業務去考慮。