共計 2105 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關如何解決 Redis 緩存異常的問題，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
緩存雪崩
緩存雪崩是指緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決方案
1、緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。
2、一般并發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
3、給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。
緩存穿透
緩存穿透是指緩存和數據庫中都沒有的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決方案
1、接口層增加校驗，如用戶鑒權校驗，id 做基礎校驗，id = 0 的直接攔截；
2、從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將 key-value 對寫為 key-null，緩存有效時間可以設置短點，如 30 秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個 id 暴力攻擊；
3、采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力。
附加
對于空間的利用到達了一種極致，那就是 Bitmap 和布隆過濾器 (Bloom Filter)。
Bitmap：典型的就是哈希表
缺點是，Bitmap 對于每個元素只能記錄 1bit 信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時間來完成了。
布隆過濾器（推薦）
就是引入了 k(k 1)k(k 1) 個相互獨立的哈希函數，保證在給定的空間、誤判率下，完成元素判重的過程。
它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。
Bloom-Filter 算法的核心思想就是利用多個不同的 Hash 函數來解決“沖突”。
Hash 存在一個沖突（碰撞）的問題，用同一個 Hash 得到的兩個 URL 的值有可能相同。為了減少沖突，我們可以多引入幾個 Hash，如果通過其中的一個 Hash 值我們得出某元素不在集合中，那么該元素肯定不在集合中。只有在所有的 Hash 函數告訴我們該元素在集合中時，才能確定該元素存在于集合中。這便是 Bloom-Filter 的基本思想。
Bloom-Filter 一般用于在大數據量的集合中判定某元素是否存在。
緩存擊穿
緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由于并發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力。和緩存雪崩不同的是，緩存擊穿指并發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。
解決方案
1、設置熱點數據永遠不過期
2、加互斥鎖，互斥鎖
緩存預熱
緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決方案
1、直接寫個緩存刷新頁面，上線時手工操作一下；
2、數據量不大，可以在項目啟動的時候自動進行加載；
3、定時刷新緩存；
緩存降級
當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。
緩存降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。
在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案：
1、一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；
2、警告：有些服務在一段時間內成功率有波動（如在 95~100% 之間），可以自動降級或人工降級，并發送告警；
3、錯誤：比如可用率低于 90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
4、嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。
服務降級的目的，是為了防止 Redis 服務故障，導致數據庫跟著一起發生雪崩問題。因此，對于不重要的緩存數據，可以采取服務降級策略，例如一個比較常見的做法就是，Redis 出現問題，不去數據庫查詢，而是直接返回默認值給用戶。
緩存熱點 key
緩存中的一個 Key(比如一個促銷商品)，在某個時間點過期的時候，恰好在這個時間點對這個 Key 有大量的并發請求過來，這些請求發現緩存過期一般都會從后端 DB 加載數據并回設到緩存，這個時候大并發的請求可能會瞬間把后端 DB 壓垮。
解決方案
對緩存查詢加鎖，如果 KEY 不存在，就加鎖，然后查 DB 入緩存，然后解鎖；其他進程如果發現有鎖就等待，然后等解鎖后返回數據或者進入 DB 查詢
關于“如何解決 Redis 緩存異常的問題”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
