• 參考黑馬Redis教程：https://www.bilibili.com/video/BV1AE411j7Wq?t=5

目錄

解決方案

快取預熱

快取雪崩

快取擊穿

快取穿透

效能指標監控

解決方案

快取預熱

• 現象：伺服器啟動後迅速當機
• 問題排查
  • 1. 請求數量較高
  • 2. 主從之間資料吞吐量較大，資料同步操作頻度較高
• 解決方案
  • 前置準備工作：
    • 1. 日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料
    • 2. 利用LRU資料刪除策略，構建資料留存佇列
      • 例如：storm與kafka配合
  • 準備工作：
    • 1. 將統計結果中的資料分類，根據級別，redis優先載入級別較高的熱點資料
    • 2. 利用分散式多伺服器同時進行資料讀取，提速資料載入過程
    • 3. 熱點資料主從同時預熱
  • 實施：
    • 1. 使用指令碼程式固定觸發資料預熱過程
    • 2. 如果條件允許，使用了CDN（內容分發網路），效果會更好
• 總結
  • 快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。
    • 避免在使用者請求的時候，先查詢資料庫，然後再將資料緩存的問題！使用者直接查詢事先被預熱的快取資料！

快取雪崩

【資料庫伺服器崩潰（1）】

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

【問題排查】

• 1. 在一個較短的時間內，快取中較多的key集中過期
• 2. 此週期內請求訪問過期的資料，redis未命中，redis向資料庫獲取資料
• 3. 資料庫同時接收到大量的請求無法及時處理
• 4. Redis大量請求被積壓，開始出現超時現象
• 5. 資料庫流量激增，資料庫崩潰
• 6. 重啟後仍然面對快取中無資料可用
• 7. Redis伺服器資源被嚴重佔用，Redis伺服器崩潰
• 8. Redis叢集呈現崩塌，叢集瓦解
• 9. 應用伺服器無法及時得到資料響應請求，來自客戶端的請求數量越來越多，應用伺服器崩潰
• 10. 應用伺服器，redis，資料庫全部重啟，效果不理想

【問題分析】

• 短時間範圍內
• 大量key集中過期

【解決方案（道）】

• 1. 更多的頁面靜態化處理
• 2. 構建多級快取架構
  • Nginx快取+redis快取+ehcache快取
• 3. 檢測Mysql嚴重耗時業務進行優化
  • 對資料庫的瓶頸排查：例如超時查詢、耗時較高事務等
• 4. 災難預警機制
  • 監控redis伺服器效能指標
  • CPU佔用、CPU使用率
  • 記憶體容量
  • 查詢平均響應時間
  • 執行緒數
• 5. 限流、降級
  • 短時間範圍內犧牲一些客戶體驗，限制一部分請求訪問，降低應用伺服器壓力，待業務低速運轉後再逐步放開訪問

【解決方案（術）】

• 1. LRU與LFU切換
• 2. 資料有效期策略調整
  • 根據業務資料有效期進行分類錯峰，A類90分鐘，B類80分鐘，C類70分鐘
  • 過期時間使用固定時間+隨機值的形式，稀釋集中到期的key的數量
• 3. 超熱資料使用永久key
• 4. 定期維護（自動+人工）
  • 對即將過期資料做訪問量分析，確認是否延時，配合訪問量統計，做熱點資料的延時
• 5. 加鎖：慎用

【總結】

• 快取雪崩就是瞬間過期資料量太大，導致對資料庫伺服器造成壓力。
  • 如能夠有效避免過期時間集中，可以有效解決雪崩現象的出現（約40%），配合其他策略一起使用，並監控伺服器的執行資料，根據執行記錄做快速調整。

• 在一個較短的時間內，快取中較多的key集中過期

快取擊穿

【資料庫伺服器崩潰（2）】

• 1. 系統平穩執行過程中
• 2. 資料庫連線量瞬間激增
• 3. Redis伺服器無大量key過期
• 4. Redis記憶體平穩，無波動
• 5. Redis伺服器CPU正常
• 6. 資料庫崩潰

【問題排查】

• 1. Redis中某個key過期，該key訪問量巨大
• 2. 多個資料請求從伺服器直接壓到Redis後，均未命中
• 3. Redis在短時間內發起了大量對資料庫中同一資料的訪問

【問題分析】

• 單個key高熱資料
• key過期

【解決方案（術）】

• 1. 預先設定
  • 以電商為例，每個商家根據店鋪等級，指定若干款主打商品，在購物節期間，加大此類資訊key的過期時長
  • 注意：購物節不僅僅指當天，以及後續若干天，訪問峰值呈現逐漸降低的趨勢
• 2. 現場調整
  • 監控訪問量，對自然流量激增的資料延長過期時間或設定為永久性key
• 3. 後臺重新整理資料
  • 啟動定時任務，高峰期來臨之前，重新整理資料有效期，確保不丟失
• 4. 二級快取
  • 設定不同的失效時間，保障不會被同時淘汰就行
• 5. 加鎖
  • 分散式鎖，防止被擊穿，但是要注意也是效能瓶頸，慎重

【總結】

• 快取擊穿就是單個高熱資料過期的瞬間，資料訪問量較大，未命中redis後，發起了大量對同一資料的資料庫訪問，導致對資料庫服務器造成壓力。
  • 應對策略應該在業務資料分析與預防方面進行，配合執行監控測試與即時調整策略，畢竟單個key的過期監控難度較高，配合雪崩處理策略即可。

快取穿透

【資料庫伺服器崩潰（3）】

• 1. 系統平穩執行過程中
• 2. 應用伺服器流量隨時間增量較大
• 3. Redis伺服器命中率隨時間逐步降低
• 4. Redis記憶體平穩，記憶體無壓力
• 5. Redis伺服器CPU佔用激增
• 6. 資料庫伺服器壓力激增
• 7. 資料庫崩潰

【問題排查】

• 1. Redis中大面積出現未命中
• 2. 出現非正常URL訪問

【問題分析】

• 獲取的資料在資料庫中也不存在，資料庫查詢未得到對應資料
• Redis獲取到null資料未進行持久化，直接返回
• 下次此類資料到達重複上述過程
• 出現黑客攻擊伺服器

【解決方案（術）】

• 1. 快取null
  • 對查詢結果為null的資料進行快取（長期使用，定期清理），設定短時限，例如30-60秒，最高5分鐘
• 2. 白名單策略
  • 提前預熱各種分類資料id對應的bitmaps，id作為bitmaps的offset，相當於設定了資料白名單。當載入正常資料時，放行，載入異常資料時直接攔截（效率偏低）
  • 使用布隆過濾器（有關布隆過濾器的命中問題對當前狀況可以忽略）
• 3. 實施監控
  • 實時監控redis命中率（業務正常範圍時，通常會有一個波動值）與null資料的佔比
  • 非活動時段波動：通常檢測3-5倍，超過5倍納入重點排查物件
  • 活動時段波動：通常檢測10-50倍，超過50倍納入重點排查物件
  • 根據倍數不同，啟動不同的排查流程。然後使用黑名單進行防控（運營）
• 4. key加密
  • 問題出現後，臨時啟動防災業務key，對key進行業務層傳輸加密服務，設定校驗程式，過來的key校驗
  • 例如每天隨機分配60個加密串，挑選2到3個，混淆到頁面資料id中，發現訪問key不滿足規則，駁回資料訪問

【總結】

• 快取穿透訪問了不存在的資料，跳過了合法資料的redis資料快取階段，每次訪問資料庫，導致對資料庫伺服器造成壓力。
• 通常此類資料的出現量是一個較低的值，當出現此類情況以毒攻毒，並及時報警。
• 應對策略應該在臨時預案防範方面多做文章。無論是黑名單還是白名單，都是對整體系統的壓力，警報解除後儘快移除。

效能指標監控

【監控指標】

• 效能指標：Performance
• 記憶體指標：Memory
• 基本活動指標：Basic activity
• 永續性指標：Persistence
• 錯誤指標：Error

【效能指標：Performance】

【記憶體指標：Memory】

【基本活動指標：Basic activity】

【永續性指標：Persistence】

【錯誤指標：Error】

【工具】

• Cloud Insight Redis
• Prometheus
• Redis-stat
• Redis-faina
• RedisLive
• zabbix

【命令】

• benchmark
• redis cli
  • monitor
  • showlog

【benchmark】

• 命令

redis-benchmark [-h ] [-p ] [-c ] [-n <requests]> [-k ]

• 範例1

redis-benchmark

• 說明：50個連線，10000次請求對應的效能
• 範例2

redis-benchmark -c 100 -n 5000

• 說明：100個連線，5000次請求對應的效能

【monitor】

• 命令

monitor

• 列印伺服器除錯資訊

• 命令

showlong [operator]

• get ：獲取慢查詢日誌
• len ：獲取慢查詢日誌條目數
• reset ：重置慢查詢日誌

【相關配置】

slowlog-log-slower-than 1000 #設定慢查詢的時間下線，單位：微妙
slowlog-max-len 100 #設定慢查詢命令對應的日誌顯示長度，單位：命令數