不管你在工作中還是面試中，Redis異常問題的解決方案都是不得不去學習瞭解的，下面來細品一下！
一、緩存穿透
1、什麼是緩存穿透？
緩存穿透是指用戶查詢數據，在數據庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到對應key的value，每次都要去數據庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫
2、有什麼解決方案來防止緩存穿透？
1、緩存空值
如果一個查詢返回的數據爲空（不管是數據不存在，還是系統故障）我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過5分鐘。通過這個設置的默認值存放到緩存，這樣第二次到緩存中獲取就有值了，而不會繼續訪問數據庫
2、採用布隆過濾器BloomFilter
.
優勢：佔用內存空間很小，位存儲；性能特別高，使用key的hash判斷key存不存在
.
將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力在緩存之前在加一層BloomFilter，在查詢的時候先去BloomFilter去查詢key是否存在，如果不存在就直接返回，存在再去查詢緩存，緩存中沒有再去查詢數據庫
二、緩存雪崩
1、什麼是緩存雪崩？
如果緩存集中在一段時間內失效，發生大量的緩存穿透，所有的查詢都落在數據庫上，造成了緩存雪崩由於原有緩存失效，新緩存未到期間所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存造成巨大壓力，嚴重的會造成數據庫宕機。
舉例來說， 我們在準備一項搶購的促銷運營活動，活動期間將帶來大量的商品信息、庫存等相關信息的查詢。 爲了避免商品數據庫的壓力，將商品數據放入緩存中存儲。 不巧的是，搶購活動期間，大量的熱門商品緩存同時失效過期了，導致很大的查詢流量落到了數據庫之上。對於數據庫來說造成很大的壓力。
2、有什麼解決方案來防止緩存雪崩？
1、加鎖排隊
mutex互斥鎖解決，Redis的SETNX去set一個mutexkey，當操作返回成功時，再進行加載數據庫的操作並回設緩存，否則，就重試整個get緩存的方法
2、數據預熱
緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題。用戶直接查詢事先被預熱的緩存數據。可以通過緩存reload機制，預先去更新緩存，再即將發生大併發訪問前手動觸發加載緩存不同的key
3、雙層緩存策略
C1爲原始緩存，C2爲拷貝緩存，C1失效時，可以訪問C2，C1緩存失效時間設置爲短期，C2設置爲長期
4、定時更新緩存策略
實效性要求不高的緩存，容器啓動初始化加載，採用定時任務更新或移除緩存
5、設置不同的過期時間，讓緩存失效的時間點儘量均勻
二、緩存預熱
1.什麼是緩存預熱
緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題。用戶直接查詢事先被預熱的緩存數據。如圖所示：
如果不進行預熱， 那麼 Redis 初識狀態數據爲空，系統上線初期，對於高併發的流量，都會訪問到數據庫中， 對數據庫造成流量的壓力。
2.有什麼解決方案？
1、數據量不大的時候，工程啓動的時候進行加載緩存動作；
2、數據量大的時候，設置一個定時任務腳本，進行緩存的刷新；
3、數據量太大的時候，優先保證熱點數據進行提前加載到緩存。
四、緩存降級
降級的情況，就是緩存失效或者緩存服務掛掉的情況下，我們也不去訪問數據庫。我們直接訪問內存部分數據緩存或者直接返回默認數據。
舉例來說：
對於應用的首頁，一般是訪問量非常大的地方，首頁裏面往往包含了部分推薦商品的展示信息。這些推薦商品都會放到緩存中進行存儲，同時我們爲了避免緩存的異常情況，對熱點商品數據也存儲到了內存中。同時內存中還保留了一些默認的商品信息。如下圖所示：
降級一般是有損的操作，所以儘量減少降級對於業務的影響程度。
五、緩存擊穿
1、什麼是緩存擊穿？
在平常高併發的系統中，大量的請求同時查詢一個key時，此時這個key正好失效了，就會導致大量的請求都打到數據庫上面去。這種現象我們稱爲緩存擊穿。這個和緩存雪崩的區別在於這裏針對某一key緩存，前者則是很多key。
2、會帶來什麼問題
會造成某一時刻數據庫請求量過大，壓力劇增
3、如何解決
1、上面的現象是多個線程同時去查詢數據庫的這條數據，那麼我們可以在第一個查詢數據的請求上使用一個互斥鎖來鎖住它。其他的線程走到這一步拿不到鎖就等着，等第一個線程查詢到了數據，然後做緩存。後面的線程進來發現已經有緩存了，就直接走緩存
2、控制同一時間訪問量