一、緩存穿透
緩存穿透：說簡單點就是大量請求的 key 根本不存在於緩存中，導致請求直接到了數據庫上，根本沒有經過緩存這一層。舉個例子：某個黑客故意製造我們緩存中不存在的 key 發起大量請求，導致大量請求落到數據庫。
解決方法：
1、接口層增加校驗，如用戶鑑權校驗，id做基礎校驗，id<=0的直接攔截；
2、布隆過濾器：布隆過濾器是一個非常神奇的數據結構，通過它我們可以非常方便地判斷一個給定數據是否存在與海量數據中。我們需要的就是判斷 key 是否合法，有沒有感覺布隆過濾器就是我們想要找的那個“人”。具體是這樣做的：把所有可能存在的請求的值都存放在布隆過濾器中，當用戶請求過來，我會先判斷用戶發來的請求的值是否存在於布隆過濾器中。不存在的話，直接返回請求參數錯誤信息給客戶端，存在的話纔會走下面的流程。
二、緩存擊穿
緩存擊穿：key對應的數據存在，但在redis中過期，此時若有大量併發請求過來，這些請求發現緩存過期一般都會從後端DB加載數據並回設到緩存，這個時候大併發的請求可能會瞬間把數據庫壓垮。
解決方法：
1、設置熱點數據永遠不過期。
2、使用互斥鎖(mutex key)。業界比較常用的做法，是使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值爲空），不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一個mutex key，當操作返回成功時，再進行load db的操作並回設緩存；否則，就重試整個get緩存的方法。
三、緩存雪崩
緩存雪崩：緩存同一時間大面積的失效，所以，後面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決辦法：
1、事前：儘量保證整個 redis 集羣的高可用性，發現機器宕機儘快補上。選擇合適的內存淘汰策略。
事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL崩掉
事後：利用 redis 持久化機制保存的數據儘快恢復緩存
2、緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生