Redis雪崩、擊穿、穿透

快取預熱

問題：伺服器啟動之後，迅速當機。

排查特徵：請求數量多，主從之間資料吞吐較大，資料同步操作頻繁。

​ 快取預熱就是系統啟動之前，提前將相關的快取資料直接載入到快取系統，避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題。使用者直接查詢實現被快取的快取資料。

方案

前期準備

• 日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料。
• 利用LRU資料刪除策略，構建資料存留佇列。

準備工作

• 將統計結果中的資料分類，根據級別，Redis優先載入級別較高的熱點資料
• 利用分散式多伺服器進行資料讀區，提供資料載入過程

實施

• 使用腳步程式固定出發預熱過程
• 如果條件允許，使用CDN（內容分發網路），效果會更好

快取雪崩

問題：

• 系統平穩執行過程中，忽然資料庫連線激增
• 應用伺服器無法及時處理請求
• 大量的408、500錯誤頁面出現
• 客戶反覆重新整理頁面獲取資料
• 資料庫崩潰
• 應用伺服器崩潰
• 重啟應用伺服器無效
• Redis伺服器崩潰
• Redis叢集崩潰
• 重啟資料庫之後再次被瞬間流量放倒

​ 短時間內，大量的快取中key集中過期。導致短週期內redis大量未命中，向資料庫請求資料，資料庫無法同時處理大量的請求，導致Redis請求被積壓並開始出現超時。此時重啟並不能解決快取中沒有資料的問題。同時，資料庫流量激增，導致資料庫崩潰；Redis大量任務積壓，資源被嚴重佔用，Redis崩潰；應用伺服器無法及時得到響應資料，來自客戶的請求激增，應用伺服器崩潰。

解決

​ 導致此問題的原因就是短時間內，大量的快取中key集中過期。所以解決方案可以有以下：

道(思想、原則)

• 更多的頁面靜態化處理，儘可能的降低從快取中取資料的次數
• 構建多級快取：Nginx快取+redis快取+ehchche快取
• 檢測資料庫中嚴重耗時的相關業務，並進行優化
• 限流、降級：短時間犧牲部分使用者的體驗，限制一部分的請求訪問，降低應用伺服器壓力，待業務穩定之後逐步放開

術(方式、方法)

• LRU(到期刪除)於LFU(按命中次數刪除)切換
• 資料有效期策略：對業務資料進行分類錯峰，比如不同類的快取資料捨得不同長度的過期時間。在同一個類裡，過期時間設定為固定時間+隨機值的形式，減少集中過期的發生
• 超熱的資料使用永久key

總結

​ 雪崩就是瞬間過期的資料量太大，導致資料庫伺服器壓力激增。如果能有效避免資料集中過期，可以有效避免雪崩的現象。

快取擊穿

​ 問題：Redis中某個key過期，該key的訪問量巨大。多個資料請求來到Redis之後，未命中。Redis就會在短時間大量訪問資料庫中的同一資料。

​ 該問題的原因是，單個key高熱，且過期。

解決

術

• 預先設定：比如電商平臺上的促銷商品
• 現場調整：監控訪問量，對自然流量激增的資料延長過期時間
• 重新整理資料：啟動定時任務，高峰來臨之前，屬性資料有效期，確保不丟失
• 二級快取：設定不同的有效時間，保證相關的key不被同時過期
• 加鎖：分散式鎖，防止被擊穿，但是要注意鎖的效能瓶頸

總結

​ 快取擊穿就是單個高熱資料過期的瞬間，資料量訪問較大，未命中Redis，對資料庫的同一資料發起大量訪問，導致資料庫伺服器壓力增大。

快取穿透

​ 問題：Redis中大面積出現為命中，出現非正常的URL。

​ 資料庫中不存在該資料，Redis獲取的null也未進行快取持久化，直接返回。下次類似的請求重複上述過程。黑客採用此方式進行攻擊。

解決方案

術

• 對查詢結果為null對資料進行快取，設定短期的過期時間（幾十秒。臨時的應對策略）。
• 白名單策略：提前預熱各種分類資料對應的ID(可使用bitmaps)。載入正常資料的時候，放行。載入異常資料的時候直接攔截(效率偏低)
• 實施監控：對Redis的命中率進行監控，如果命中率和null比較，超過平時正常業務範圍的幾十倍，那麼啟動相應的排出流程，可加入黑名單