緩存穿透
引發原因:
在查詢一個一定不存在的數據，由於緩存是不命中時被動寫入，並且處於容錯考慮，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，緩存層失去意義。
當在大流量流入時，可能因爲頻繁訪問存儲層導致DB直接宕機，這樣會形成被人利用不存在的key頻繁攻擊應用的漏洞。
-----------------解決方法:
1.最爲常簡的是採用布隆過濾器，將所有可能存在的數據哈希到一個足夠發的 bigmap 中，一個一定不存在的數據會被該 bigmap 攔截掉，從而避免對底層存儲系統造成查詢壓力。
2.另一種更爲簡單的方法，如果一個查詢返回的數據爲空（無論數據爲空，或是系統故障），將空結果進行緩存，設置一個最長不超過五分鐘的過期時間。
緩存雪崩
引發原因
設置緩存時採用了相同的過期時間，導致緩存在某時刻同時失效，請求全部轉向DB，DB瞬時壓力過重雪崩。
解決方案
在緩存失效後，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。
簡單方案就是將緩存失效時間分散開，我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重複率就會降低，就很難引發集體失效的事件。
----------------引發原因
Redis宕機，導致客戶端的請求之間流向DB，拖垮DB。
解決方案
1.保持緩存層服務器的高可用。
–監控、集羣、哨兵。當一個集羣裏面有一臺服務器有問題，讓哨兵踢出去。
2.依賴隔離組件爲後端限流並降級。
比如推薦服務中，如果個性化推薦服務不可用，可以降級爲熱點數據。
3.提前演練。
演練 緩存層crash後，應用以及後端的負載情況以及可能出現的問題。 對此做一些預案設定。
-------------緩存穿透
引發原因：
緩存穿透是指緩存和數據庫中都沒有的數據，而用戶不斷髮起請求，如發起爲id爲“-1”的數據或id爲特別大不存在的數據。這時的用戶很可能是攻擊者，攻擊會導致數據庫壓力過大。
解決方案：
1.接口層增加校驗，如用戶鑑權校驗，id做基礎校驗，id<=0的直接攔截；
2.從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫爲key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反覆用同一個id暴力攻擊
-------------緩存擊穿
引發原因：
緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由於併發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力
解決方案：
1.設置熱點數據永遠不過期。
2.加互斥鎖，例如----------
緩存雪崩
引發原因：
緩存雪崩是指緩存中數據大批量到過期時間，而查詢數據量巨大，引起數據庫壓力過大甚至down機。和緩存擊穿不同的是， 緩存擊穿指併發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。
解決方案：
緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。
如果緩存數據庫是分佈式部署，將熱點數據均勻分佈在不同搞得緩存數據庫中。
設置熱點數據永遠不過期。