(Redis學習筆記):Redis解決方案

Asinmy 發表於 2020-11-29

目錄

解決方案

快取預熱

快取雪崩

快取擊穿

快取穿透

效能指標監控

解決方案

快取預熱

  • 現象:伺服器啟動後迅速當機
  • 問題排查
    • 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%),配合其他策略一起使用,並監控伺服器的執行資料,根據執行記錄做快速調整。

(Redis學習筆記):Redis解決方案

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

(Redis學習筆記):Redis解決方案

快取擊穿

【資料庫伺服器崩潰(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】

(Redis學習筆記):Redis解決方案

【記憶體指標:Memory】

(Redis學習筆記):Redis解決方案

【基本活動指標:Basic activity】

(Redis學習筆記):Redis解決方案

【永續性指標:Persistence】

(Redis學習筆記):Redis解決方案

【錯誤指標:Error】

(Redis學習筆記):Redis解決方案

【工具】

  • 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次請求對應的效能

(Redis學習筆記):Redis解決方案

【monitor】

  • 命令
monitor
  • 列印伺服器除錯資訊
【showlong】
  • 命令
showlong [operator]
  • get :獲取慢查詢日誌
  • len :獲取慢查詢日誌條目數
  • reset :重置慢查詢日誌

【相關配置】

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