Redis緩存三大異常如何處理

本文小編為大家詳細介紹“Redis緩存三大異常如何處理”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Redis緩存三大異常如何處理”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

一、背景

Redis是一個完全開源的、遵守BSD協議的、高性能的key-value數據結構存儲系統，它支持數據的持久化，可以將內存中的數據保存在磁盤中，而且不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲，功能十分強大，Redis還支持數據的備份，即master-slave模式的數據備份，從而提高可用性。當然最重要的還是讀寫速度快，作為我們平常開發中最常用的緩存方案被廣泛應用。但在實際應用過程中，它會存在緩存雪崩、緩存擊穿和緩存穿透等異常情況，如果忽視這些情況可能會帶來災難性的后果，下面主要對這些緩存異常和常見處理方案進行相應分析與總結。

二、緩存雪崩

（一）是什么

一段時間內本應在redis緩存中處理的大量請求，都發送到了數據庫進行處理，導致對數據庫的壓力迅速增大，嚴重時甚至可能導致數據庫崩潰，從而導致整個系統崩潰，就像雪崩一樣，引發連鎖效應，所以叫緩存雪崩。

（二）為什么

出現上述情況的常見原因主要有以下兩點：

• 大量緩存數據同時過期，導致本應請求到緩存的需重新從數據庫中獲取數據。

• redis本身出現故障，無法處理請求，那自然會再請求到數據庫那里。

（三）怎么辦

針對大量緩存數據同時過期的情況：

• 實際設置過期時間時，應當盡量避免大量key同時過期的場景，如果真的有，那就通過隨機、微調、均勻設置等方式設置過期時間，從而避免同一時間過期。

• 添加互斥鎖，使得構建緩存的操作不會在同一時間進行。

• 雙key策略，主key是原始緩存，備key為拷貝緩存，主key失效時，可以訪問備key，主key緩存失效時間設置為短期，備key設置為長期。

• 后臺更新緩存策略，采用定時任務或者消息隊列的方式進行redis緩存更新或移除等。

針對redis本身出現故障的情況：

• 在預防層面，可以通過主從節點的方式構建高可用的集群，也就是實現主Redis實例掛掉后，能有其他從庫快速切換為主庫，繼續提供服務。

• 如果事情已經發生了，那就要為了防止數據庫被大量的請求搞崩潰，可以采用服務熔斷或者請求限流的方法。當然服務熔斷相對粗暴一些，停止服務直到redis服務恢復，請求限流相對溫和一些，保證一些請求可以處理，不是一刀切，不過還是看具體業務情況選擇合適的處理方案。

三、緩存擊穿

（一）是什么

緩存擊穿一般出現在高并發系統中，是大量并發用戶同時請求到緩存中沒有但數據庫中有的數據，也就是同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大。和緩存雪崩不同的是，緩存擊穿指并發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。

（二）為什么

這種情況其實一般出現的原因就是某個熱點數據緩存過期，由于是熱點數據，請求并發量又大，所以過期的時候還是會有大量請求同時過來，來不及更新緩存就全部打到數據庫那邊了。

（三）怎么辦

針對這種情況有兩種常見的處理方案：

• 簡單粗暴的對熱點數據不設置過期時間，這樣不會過期，自然也就不會出現上述情況了，如果后續想清理，可以通過后臺進行清理。

• 添加互斥鎖，即當過期之后，除了請求過來的第一個查詢的請求可以獲取到鎖請求到數據庫，并再次更新到緩存中，其他的會被阻塞住，直到鎖被釋放，同時新的緩存也被更新上去了，后續請求又會請求到緩存上，這樣就不會出現緩存擊穿了。

四、緩存穿透

（一）是什么

緩存穿透是指數據既不在redis中，也不在數據庫中，這樣就導致每次請求過來的時候，在緩存中找不到對應key之后，每次都還要去數據庫再查詢一遍，發現數據庫也沒有，相當于進行了兩次無用的查詢。這樣請求就可以繞過緩存直接查數據庫，如果這個時候有人想惡意攻擊系統，就可以故意使用空值或者其他不存在的值進行頻繁請求，那么就會對數據庫造成比較大的壓力。

（二）為什么

這種現象的原因其實很好理解，業務邏輯里面如果用戶對某些信息還沒有進行相應的操作或者處理，那對應的存放信息的數據庫或者緩存中自然也就沒有相應的數據，也就容易出現上述問題。

（三）怎么辦

針對緩存穿透，一般有以下三種處理方案：

• 非法請求的限制，主要是指參數校驗、鑒權校驗等，從而一開始就把大量的非法請求攔截在外，這在實際業務開發中是必要的手段。

• 緩存空值或者默認值，如果從緩存取不到的數據，在數據庫中也沒有取到，那我們仍然把這個空結果進行緩存，同時設置一個較短的過期時間。通過這個設置的默認值存放到緩存，這樣第二次到緩存中獲取就有值了，而不會繼續訪問數據庫，可以防止有大量惡意請求是反復用同一個key進行攻擊。

• 使用布隆過濾器快速判斷數據是否存在。那什么是布隆過濾器呢，簡單來說，就是可以引入了多個相互獨立的哈希函數，保證在給定的空間和誤判率下，完成元素判重。因為我們知道，存在hash碰撞這樣一種情況，那如果只使用一個hash函數，則碰撞沖突的概率明顯會變大，那為了減少這種沖突，我們可以多引入幾個hash函數，而布隆過濾器算法的核心思想就是利用多個不同的hash函數來解決這樣一種沖突。它的優點是空間效率高，查詢時間短，遠超其他算法，而它的缺點就是會存在一定的誤識別率，它不能完全保證請求過來的key，通過布隆過濾器的校驗，就一定有這個數據，畢竟理論上還是會存在沖突情況，無論概率多小。但是，只要沒有通過布隆過濾器的校驗，那么這個key就一定不存在，只要利用這一點其實就已經可以過濾掉大部分不存在的key的請求了，在正常場景下已然足夠了。

五、其他

除了上述三種常見的Redis緩存異常問題之外，還經常聽到的有緩存預熱和緩存降級兩個名詞，與其說是異常問題，不如說是兩種的優化處理方法。

（一）緩存預熱

緩存預熱就是系統上線前后，將相關的緩存數據直接加載到緩存系統中去，而不依賴用戶。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題。用戶直接查詢事先被預熱的緩存數據，這樣可以避免那么系統上線初期，對于高并發的流量，都會訪問到數據庫中， 對數據庫造成流量的壓力。

根據數據不同量級，可以有以下幾種做法：

• 數據量不大：項目啟動的時候自動進行加載。

• 數據量較大：后臺定時刷新緩存。

• 數據量極大：只針對熱點數據進行預加載緩存操作。

（二）緩存降級

緩存降級是指當緩存失效或緩存服務出現問題時，為了防止緩存服務故障，導致數據庫跟著一起發生雪崩問題，所以也不去訪問數據庫，但因為一些原因，仍然想要保證服務還是基本可用的，雖然肯定會是有損服務。因此，對于不重要的緩存數據，我們可以采取服務降級策略。

一般做法有以下兩種：

• 直接訪問內存部分的數據緩存。

• 直接返回系統設置的默認值。

讀到這里，這篇“Redis緩存三大異常如何處理”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。