企業級解決方案-快取預熱、快取雪崩、快取擊穿、快取穿透
阿新 • • 發佈：2021-09-19
目錄
企業級解決方案
1. 快取預熱
問題：
伺服器啟動後迅速宕機
問題排查
1. 請求數量較高
2. 主從之間資料吞吐量較大，資料同步操作頻度較高
解決方案
前置準備工作： 1. 日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料 2. 利用LRU資料刪除策略，構建資料留存佇列 例如：storm與kafka配合 準備工作： 1. 將統計結果中的資料分類，根據級別，redis優先載入級別較高的熱點資料 2. 利用分散式多伺服器同時進行資料讀取，提速資料載入過程 3. 熱點資料主從同時預熱 實施： 1. 使用指令碼程式固定觸發資料預熱過程 2. 如果條件允許，使用了CDN（內容分發網路），效果會更好
總結
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
2.快取雪崩
資料庫伺服器崩潰
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%），配合其他策略一起使用，並監控伺服器的執行資料，根據執行記錄做快速調整。
3.快取擊穿
資料庫伺服器崩潰
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的過期監控難度較高，配合雪崩處理策略即可。
4.快取穿透
資料庫伺服器崩潰
1. 系統平穩執行過程中
2. 應用伺服器流量隨時間增量較大
3. Redis伺服器命中率隨時間逐步降低
4. Redis記憶體平穩，記憶體無壓力
5. Redis伺服器CPU佔用激增
6. 資料庫伺服器壓力激增
7. 資料庫崩潰
問題排查
1. Redis中大面積出現未命中
2. 出現非正常URL訪問
問題分析
獲取的資料在資料庫中也不存在，資料庫查詢未得到對應資料
Redis獲取到null資料未進行持久化，直接返回
下次此類資料到達重複上述過程
出現黑客攻擊伺服器
解決方案
1. 快取null
對查詢結果為null的資料進行快取（長期使用，定期清理），設定短時限，例如30-60秒，最高5分鐘
2. 白名單策略
(1)提前預熱各種分類資料id對應的bitmaps，id作為bitmaps的offset，相當於設定了資料白名單。當載入正常 資料時，放行，載入異常資料時直接攔截（效率偏低）
(2)使用布隆過濾器（有關布隆過濾器的命中問題對當前狀況可以忽略）
3. 實施監控
實時監控redis命中率（業務正常範圍時，通常會有一個波動值）與null資料的佔比
非活動時段波動：通常檢測3-5倍，超過5倍納入重點排查物件
活動時段波動：通常檢測10-50倍，超過50倍納入重點排查物件
根據倍數不同，啟動不同的排查流程。然後使用黑名單進行防控（運營）
4. key加密
問題出現後，臨時啟動防災業務key，對key進行業務層傳輸加密服務，設定校驗程式，過來的key校驗
例如每天隨機分配60個加密串，挑選2到3個，混淆到頁面資料id中，發現訪問key不滿足規則，駁回資料訪問
總結
快取擊穿訪問了不存在的資料，跳過了合法資料的redis資料快取階段，每次訪問資料庫，導致對資料庫伺服器造成壓力。通常此類資料的出現量是一個較低的值，當出現此類情況以毒攻毒，並及時報警。應對策略應該在臨時預案防範方面多做文章。
無論是黑名單還是白名單，都是對整體系統的壓力，警報解除後儘快移除。
5.效能指標監控
監控指標
效能指標：Performance
記憶體指標：Memory
基本活動指標：Basic activity
永續性指標：Persistence
錯誤指標：Error
效能指標：Performance
| Name | Description |
|---|---|
| latency | Redis響應一個請求的時間 |
| instantaneous_ops_per_sec | 平均每秒處理請求總數 |
| hit rate (calculated) | 快取命中率（計算出來的） |
記憶體指標：Memory
| Name | Description |
|---|---|
| used_memory | 已使用記憶體 |
| mem_fragmentation_ration | 記憶體碎片率 |
| evicted_keys | 由於最大記憶體限制被移除的key的數量 |
| blocked_clients | 由於BLPOP、BRPOP、or BRPOPLPUSH而被阻塞的客戶端 |
基本活動指標：Basic activity
| Name | Description |
|---|---|
| connected_clients | 客戶端連線數 |
| connected_slaves | Slave數量 |
| master_last_io_seconds_ago | 最近一次主從互動之後的秒數 |
| keyspace | 資料庫中的key值總數 |
永續性指標：Persistence
| Name | Description |
|---|---|
| rdb_last_save_time | 最後一次持久化儲存到磁碟的時間數 |
| rdb_changes_since_last_save | 自最後一次持久化以來資料庫的更改數 |
錯誤指標：Error
| Name | Description |
|---|---|
| rejected_connections | 由於達到maxclient限制而被拒絕的連線數 |
| keyspace_misses | key值查詢失敗（沒有命中）次數 |
| master_link_down_since_seconds | 主從斷開的持續時間（以秒為單位） |
監控方式
工具
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 慢查詢日誌
命令
showlong [operator]
get ：獲取慢查詢日誌
len ：獲取慢查詢日誌條目數
reset ：重置慢查詢日誌
相關配置
slowlog-log-slower-than 1000 #設定慢查詢的時間下線，單位：微妙
slowlog-max-len 100 #設定慢查詢命令對應的日誌顯示長度，單位：命令數