Redis 企業級解決方案（緩存預熱 緩存雪崩 緩存擊穿）（十二）

1. 緩存預熱

• 問題
  服務器啓動後迅速宕機
• 問題分析

• 請求數量較高
• 主從之間數據吞吐量較大，數據同步操作頻度較高

• 解決方案

  • 前置準備工作
    • 日常例行統計數據訪問記錄，統計訪問頻度較高的熱點數據
    • 利用LRU數據刪除策略，構建數據留存隊列例如：storm和kfafa配合、
  • 準備工作
    • 將統計結果中的數據分類，根據級別，redis優先加載級別較高的熱點數據
    • 利用分佈式多服務器同時進行數據讀取，提速數據加載過程
    • 熱點數據主從同時預熱
  • 實施
    • 使用腳本程序固定觸發數據預熱過程
    • 如果條件允許，使用了CDN（內容分發網絡），效果會更好

• 總結
  緩存預熱就是系統啓動前，提前將相關的緩存數據直接加載到緩存系統。避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題，將熱點數據提前緩存，用戶直接查詢事先被預熱的緩存數據。

2. 緩存雪崩

緩存雪崩就是當Redis服務器重啓或者大量緩存數據在同一時期失效時,請求全部轉發到數據庫,數據庫有可能會因爲承受不住而宕機

• 解決方案

• 更多的頁面靜態化處理
• 構建多級緩存架構 Nginx緩存+redis緩存+ehcache緩存
• LRU 與LFU 切換
• 數據有效期策略調整
  根據業務數據有效期進行分類錯峯，A類90分鐘，B類80分鐘，C類70分鐘
  過期時間使用固定時間+隨機值的形式，稀釋集中到期的key的數量
• 超熱數據使用永久可以
• 定期維護（自動+人工），對即將過期數據做訪問量分析，確認是否延時，配合訪問量統計，做熱點數據延時
• 加鎖（慎用）

3. 緩存穿透

緩存擊穿訪問了不存在的數據，跳過了合法數據的redis數據緩存階段，每次訪問數據庫，導致對數據庫服務器造成壓力(一般這種情況出現多爲黑客攻擊）。

• 解決方案

• 緩存null
  對查詢結果爲null的數據進行緩存（長期使用，定期清理），設定短時限，例如30-60秒，最高5分鐘
• 白名單策略
  提前預熱各種分類數據id對應的bitmaps，id作爲bitmaps的offset，相當於設置了數據白名單。當加載正常數據時，放 行，加載異常數據時直接攔截（效率偏低）
  使用布隆過濾器（有關布隆過濾器的命中問題對當前狀況可以忽略）
• 實施監控
  實時監控redis命中率（業務正常範圍時，通常會有一個波動值）與null數據的佔比
  非活動時段波動：通常檢測3-5倍，超過5倍納入重點排查對象
  活動時段波動：通常檢測10-50倍，超過50倍納入重點排查對象
  根據倍數不同，啓動不同的排查流程。然後使用黑名單進行防控（運營）

如有不足之處，歡迎指正，謝謝！