Redis緩存雪崩、擊穿、穿透

目錄

• 1、緩存三大問題
• 2、緩存雪崩
  • 2.1 雪崩場景
  • 2.1 應對方案
• 3、緩存擊穿
  • 3.1 擊穿場景
  • 3.2 應對方案
• 4、緩存穿透
  • 4.1 穿透場景
  • 4.2 應對方案

1、緩存三大問題

這三個問題一旦發生，就會致使大量請求進入後臺的數據庫，若是有大量併發同時到達數據庫，有可能會致使數據庫宕機，影響業務，也有可能會致使一系列連鎖反映，極可能致使業務長時間沒法恢復。

接下來本文詳細介紹這三個問題的發生場景以及對應的解決方案。

2、緩存雪崩

2.1 雪崩場景

雪崩是指大量請求沒法在redis進行處理，本來預期在redis的中存在的數據卻在redis中不存在，緊接着這些請求被所有轉發到了數據庫，致使暑數據庫壓力大增。產生雪崩的緣由主要有兩個：

1. 緩存中有大量的數據同時過時，致使大量請求沒法在redis中沒法處理。
2. Redis宕機

2.1 應對方案

針對緩存中有大量的數據同時過時的應對方案

1. 避免給大量業務數據設置相同的過時時間，業務場景中總會出現同時實效的case，好比基於訂單的下單時間。對於這種場景，能夠在過時時間後面加個隨機的時間好比（1-3分鐘）。這樣既保證了業務基本在相近的時間過時，也不會在同時間集中過時。
2. 降級，若是雪崩已經產生，能夠對業務進行降級，非核心數據直接返回指定的靜態數據（緩存中沒有也不去數據庫請求），只有核心數據持續訪問緩存（若是緩存沒有，也能夠去訪問數據庫，因爲限制了非核心數據的請求，這個時候db的壓力應該不大）。

針對Redis宕機應對方
redis宕機就等於全部數據同時失效，等於最強雪崩，redis所能承載的qps是萬級別，而單個數據庫所能承載的qps是千級別，這個時候若是全部請求所有進入DB，必然會致使DB的奔潰。有兩個處理方法。

1. 服務完全熔斷，當前進來後直接返回，再也不訪問數據庫，對服務使用方來講，整個服務是不可用的，對業務的影響最大，可是完全保護了數據庫。

2. 請求限流，在業務系統的請求入口控制每秒進入服務的次數，限流的比例能夠基於以前的數據進行分析，好比在雪崩前入口的qps是10000，其中9000被redis承載，1000進入了數據庫（說明數據庫能承載1000的qps），那麼這個時候能夠將入口的qps 限制爲1000，這樣既保證了數據庫的安全，也不至於業務不可用（部分可用狀態）。限流示意圖以下。

3. 主從集羣部署，實現redis的高可用，當主節點宕機後從節點能夠切換爲主節點繼續提供服務。

固然宕機後的一系列處理方法一樣適用於大量key同事過時的case。

3、緩存擊穿

3.1 擊穿場景

熱點數據在redis中找不到，和雪崩相比，擊穿對應的熱點數據數據量比較小，可是這些數據的請求量很是高，致使大量請求都被大到了數據庫。
擊穿發生在熱點數據失效時。

3.2 應對方案

對於緩存擊穿解決方案比較簡單，對於熱點數據能夠設置永不過時，這樣就解決了失效問題。

4、緩存穿透

4.1 穿透場景

緩存穿透是指查詢的數據既不在緩存也不在數據庫，請求redis時候發現緩存缺失，再去訪問數據庫，發現數據庫也沒有，因此沒法補全緩存數據，致使每次查詢都會去請求數據庫，當有
大量相似的請求場景時候，也會對數據庫形成巨大的壓力。
發生穿透的場景：

1. 業務誤操做致使本應該存在的數據被誤刪除
2. 惡意攻擊，專門查詢數據庫中沒有的數據，利用穿透的漏洞。
3. 設計問題，代碼不嚴謹，已知可能爲空的數據沒有去作判斷。

4.2 應對方案

有三個方法能夠解決穿透問題。

1. 給緩存賦空值或者缺省值，一旦發現沒有業務數據，能夠賦爲空置或者留一個標示值，好比有值的時候對應的值是一個list，若是發現沒有業務數據能夠付一個空的list，這樣等下次再來訪問時，發現redis已經有缺省值，能夠直接返回，避免了屢次訪問數據庫。
2. 經過業務規則判斷，若是經過某些規則就能夠知道沒有數據，則能夠直接不用訪問。
3. 使用布隆過濾器，能夠快速判斷數據是否存在，避免從數據庫中查詢是否存在，減輕數據庫的壓力。原理和相關使用後期專門寫一篇文章介紹。

本文完。