作為一個內存數據庫，redis也總是免不了有各種各樣的問題，這篇文章主要是針對其中三個問題進行講解：緩存穿透、緩存擊穿和緩存雪崩。並給出一些解決方案。這三個問題是基本問題也是面試常問問題。
這篇文章我參考了很多篇，發現寫的基本上一樣，所以在此基礎之上進行改進。內容是我在某字母網站看的尚硅谷的教程總結的。特在此說明。
一、緩存穿透
1、概念
緩存穿透的概念很簡單，用戶想要查詢一個數據，發現redis內存數據庫沒有，也就是緩存沒有命中，於是向持久層數據庫查詢。發現也沒有，於是本次查詢失敗。當用戶很多的時候，緩存都沒有命中，於是都去請求了持久層數據庫。這會給持久層數據庫造成很大的壓力，這時候就相當於出現了緩存穿透。
這里需要注意和緩存擊穿的區別，緩存擊穿，是指一個key非常熱點，在不停的扛着大並發，大並發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大並發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。
為了避免緩存穿透其實有很多種解決方案。下面介紹幾種。
2、解決方案
（1）布隆過濾器
布隆過濾器是一種數據結構，垃圾網站和正常網站加起來全世界據統計也有幾十億個。網警要過濾這些垃圾網站，總不能到數據庫里面一個一個去比較吧，這就可以使用布隆過濾器。假設我們存儲一億個垃圾網站地址。
可以先有一億個二進制比特，然后網警用八個不同的隨機數產生器（F1,F2, …,F8） 產生八個信息指紋（f1, f2, …, f8）。接下來用一個隨機數產生器 G 把這八個信息指紋映射到 1 到1億中的八個自然數 g1, g2, …,g8。最后把這八個位置的二進制全部設置為一。過程如下：
有一天網警查到了一個可疑的網站，想判斷一下是否是XX網站，首先將可疑網站通過哈希映射到1億個比特數組上的8個點。如果8個點的其中有一個點不為1，則可以判斷該元素一定不存在集合中。
那這個布隆過濾器是如何解決redis中的緩存穿透呢？很簡單首先也是對所有可能查詢的參數以hash形式存儲，當用戶想要查詢的時候，使用布隆過濾器發現不在集合中，就直接丟棄，不再對持久層查詢。
這個形式很簡單。
（2）緩存空對象
當存儲層不命中后，即使返回的空對象也將其緩存起來，同時會設置一個過期時間，之后再訪問這個數據將會從緩存中獲取，保護了后端數據源；
但是這種方法會存在兩個問題：
如果空值能夠被緩存起來，這就意味着緩存需要更多的空間存儲更多的鍵，因為這當中可能會有很多的空值的鍵；
即使對空值設置了過期時間，還是會存在緩存層和存儲層的數據會有一段時間窗口的不一致，這對於需要保持一致性的業務會有影響。
二、緩存擊穿
1、概念
緩存擊穿，是指一個key非常熱點，在不停的扛着大並發，大並發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大並發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。
2、解決方案
可以將熱點數據設置為永遠不過期；或者基於 redis or zookeeper 實現互斥鎖，等待第一個請求構建完緩存之后，再釋放鎖，進而其它請求才能通過該 key 訪問數據。
三、緩存雪崩
1、概念
緩存雪崩是指當緩存服務器重啟、宕機或者大量緩存集中在某一個時間段失效，這樣在失效的時候，會給后端系統(比如DB)帶來很大壓力。
緩存層出現了錯誤，不能正常工作了。於是所有的請求都會達到存儲層，存儲層的調用量會暴增，造成存儲層也會掛掉的情況。
比如系統 A，假設每天高峰期每秒 5000 個請求，本來緩存在高峰期可以扛住每秒 4000 個請求，但是緩存機器意外發生了全盤宕機。緩存掛了，此時 1 秒 5000 個請求全部落數據庫，數據庫必然扛不住，它會報一下警，然后就掛了。此時，如果沒有采用什么特別的方案來處理這個故障，DBA 很着急，重啟數據庫，但是數據庫立馬又被新的流量給打死了。
2、解決方案
（1）redis高可用
這個思想的含義是，既然redis有可能掛掉，那我多增設幾台redis，這樣一台掛掉之后其他的還可以繼續工作，其實就是搭建的集群。
（2）限流降級
這個解決方案的思想是，在緩存失效后，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。
（3）數據預熱
數據加熱的含義就是在正式部署之前，我先把可能的數據先預先訪問一遍，這樣部分可能大量訪問的數據就會加載到緩存中。在即將發生大並發訪問前手動觸發加載緩存不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻。
3、總結
緩存雪崩的事前事中事后的解決方案如下。
- 事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰。
- 事中：本地 ehcache 緩存 + hystrix 限流&降級，避免 MySQL 被打死。
- 事后：redis 持久化，一旦重啟，自動從磁盤上加載數據，快速恢復緩存數據。
用戶發送一個請求，系統 A 收到請求后，先查本地 ehcache 緩存，如果沒查到再查 redis。如果 ehcache 和 redis 都沒有，再查數據庫，將數據庫中的結果，寫入 ehcache 和 redis 中。
限流組件，可以設置每秒的請求，有多少能通過組件，剩余的未通過的請求，怎么辦？走降級！可以返回一些默認的值，或者友情提示，或者空白的值。
好處：
- 數據庫絕對不會死，限流組件確保了每秒只有多少個請求能通過。
- 只要數據庫不死，就是說，對用戶來說，2/5 的請求都是可以被處理的。
- 只要有 2/5 的請求可以被處理，就意味着你的系統沒死，對用戶來說，可能就是點擊幾次刷不出來頁面，但是多點幾次，就可以刷出來一次。
http://baijiahao.baidu.com/s?id=1655304940308056733&wfr=spider&for=pc