緩存預熱

在高請求之前，做好一系列措施，保證大量用戶數量點擊造成災難。

請求數量較高

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

緩存預熱解決方案

前置準備工作：

日常例行統計數據訪問記錄，統計訪問頻度較高的熱點數據

利用LRU數據刪除策略，構建數據留存隊列
例如：storm與kafka配合

準備工作：

將統計結果中的數據分類，根據級別，redis優先加載級別較高的熱點數據

利用分布式多服務器同時進行數據讀取，提速數據加載過程

實施：

使用腳本程序固定出大數據預熱過程

如果條件允許，使用CDN（內容分發網絡），效果會更好

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

緩存雪崩

數據庫服務器崩潰（1）

系統平穩運行過程中，忽然數據庫連接量激增

應用服務器無法及時請求

大量408，500錯誤頁面出現

客戶反復刷新頁面獲取數據

數據庫崩潰

應用服務器崩潰

重啟應用服務器無效

Redis服務器崩潰

Redis集群崩潰

重啟數據庫之后再次被瞬間流量放倒

問題排查

在一個較短的時間內，緩存中較多的key集中過期（關鍵所在）

此周期內請求訪問過期的數據，redis未命中，redis向數據庫獲取數據

數據庫同時接受到大量的請求無法即時處理

Redis大量請求被積壓，開始出現超時現象

數據庫流量激增，數據庫崩潰

重啟后任然面對緩存中無數據可用

Redis服務器資源被嚴重占用，Redis服務器崩潰

Redis集群呈現崩塌，集群瓦解

應用服務器無法即時得到數據響應請求，來自客戶端的請求數量越來越多，應用服務器崩潰

應用服務器，redis，數據庫全部重啟，效果不理想

問題分析

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

解決方案（道）

更多的頁面靜態化處理

構建多級緩存架構
Nginx緩存+redis緩存+ehcache緩存

檢測Mysql嚴重耗時業務進行優化
對數據庫的瓶頸排查：例如超時查詢、耗時較高事務等

災難預警機制
監控redis服務器性能指標
1、CPU占用、CPU使用率
2、內存容量
3、查詢平均響應時間
4、線程數

限流、降級
短時間范圍內習生一些客戶體驗，限制一部分請求訪問，降低應用服務器壓力，待業務低速運轉后再逐漸放開訪問

解決方案（術）

LRU與LFU切換

數據有效期策略調整
根據業務數據有效期進行分類錯峰，A類90分鐘，B類80分鐘，C類70分鐘
過期時間使用固定形式+隨機值的形式，稀釋集中到期的key的數量

超熱數據使用永久key

定期維護（自動+人工）
對即將過期數據做訪問量分析，確認是否演示，配合訪問量統計，做熱點數據的延時

加鎖 慎用！！！！！！！

總結
緩存雪崩式瞬間過期數量太大，導致對數據庫服務器造成壓力。如果能有效避免過期時間集中，可以有效解決雪崩現象的出現（約40%）。配合其他策略一起使用，并監控服務器的運行數據，根據運行巨鹿做快速調整

緩存擊穿

數據庫服務器崩潰（2）

系統平穩運行過程中

數據庫連接量瞬間激增

Redis服務器無大量key過期

Redis內存平穩，無波動

Redis服務器CPU正常

數據庫崩潰

問題排查

Redis中某個key過期，該key訪問量巨大

多個數據請求從服務器直接壓到Redis后，均為命中

Redis在短時間內發起了大量對數據庫中同一個數據的訪問

問題分析

• 單個key高熱數據
• key過期

解決方案（術）

預先設定
以電商為例，每個商家根據店鋪等級，指定若干款主打商品，在購物節期間，加大此類信息key的過期時常
注意：購物節不僅僅指當天，以及后續若干天，訪問峰值呈現逐漸降低趨勢

現場調整
監控訪問量，對自然流量激增的數據延長過期時間或設置為永久性key

后臺刷新數據
啟動定時任務，高峰期來臨之前，刷新數據有效期，保存不丟失

二級緩存
設置不同的失效時間，保障不會被同時淘汰就行

加鎖
分布式鎖，防止被擊穿，但是要注意也是性能瓶頸，慎重！！！！！！！！

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

緩存穿透

數據庫服務器崩潰（3）

系統平穩運行過程中

應用服務器流量隨時間增量較大

Redis服務器命中率隨時間逐步降低

Redis內存平穩，內存無壓力

Redis服務器CPU占用激增

數據庫服務器壓力激增

數據庫崩潰

問題排查

redis中大面積出現未命中

出現非正常URL訪問

問題分析

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

解決方法（術）

緩存null
對查詢結果為null的數據進行緩存（長期使用，定期清理），設定短時限，例如30-60秒，最高五分鐘

白名單策略
提前預熱各種分類數據id對應的bitmaps,id作為bitmaps的offset,相當于設置了數據白名單。當加載正常數據后放型，加載異常數據時直接攔截（效率偏低）
使用布隆過濾器（有關布隆過濾器的命中問題對當前狀態可以忽略）

實時監控
試試監控redis命中率（業務正常范圍時，通常回有一個波動值）與null數據的占比
非活動時間波動：通常檢測3-5倍，超過5倍納入重點排查對象
活動時間波動：通常檢測10-50倍，超過50倍納入重點排查對象
根據倍數不同，啟動不同的排查流程。然后使用黑名單進行防控（運營）

key加密
問題出現后，臨時啟動防災業務key,對key進行業務層傳輸加密服務，設定校驗程序，過來的key校驗
例如每天隨機分配60個加密串，挑選2-3個，混淆到頁面數據id中，發現訪問key不滿足規則，駁回數據訪問

總結
緩存穿透是訪問了不存在的數據，跳過了合法數據的redis數據緩存階段，每次訪問數據庫，導致對數據庫服務器造成壓力。通常此類數據的出現量是一個較低的值，當出現此類情況以毒攻毒，并即時報警。應對策略應該在臨時預案防范方面多做文章
無論是黑名單還是白名單，都是對整體系統的壓力，警報解除后盡快移除

性能指標監控

性能指標

• 性能指標：Performance
  

• 內存指標：Memory
  

• 基本活動指標：Basic activity
  

• 持久性指標：Persistence
  

• 錯誤指標：Error
  

監控方式

工具

• Cloud Insght Redis
• Prometheus
• Redis-stat
• Redis-faina
• RedisLive
• zabbix
  命令
• benchmark
• redis cli
  monitor
  showlog

benchmark

monitor’

slowlog

總結

以上是生活随笔為你收集整理的【Redis】18.缓存预热、缓存雪崩、缓存击穿、缓存穿透、性能指标监控等企业级解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。