緩存預熱
- 問題排查
- 請求數據較高
- 主從之間數據吞吐量較大，數據同步操作頻度較高
- 解決方案
- 前置準備工作
- 日常例行統計數據訪問記錄，統計訪問頻度較高的熱點數據
- 利用LRU數據刪除策略，構建數據留存隊列
例如：storm與kafka配合
- 準備工作
- 將統計結果中的數據分類，根據級別，redis優先加載級別較高的熱點數據
- 利用分佈式多服務器同時進行數據讀取，提速數據加載過程
- 實施：
- 使用腳本程序固定觸發數據預熱過程
- 如果條件允許，使用了CDN（內容分發網絡），效果會更好
- 總結
緩存預熱就是系統啓動前，提前將相關的緩存數據直接加載到緩存系統，避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題，用戶之間查詢事先被預熱的緩存數據！
緩存雪崩
- 數據庫服務器奔潰（1）
- 系統平穩運行過程中，忽然數據庫連接量激增
- 應用服務器無法及時處理請求
- 大量408，500錯誤頁面出現
- 客戶反覆刷新頁面獲取數據
- 數據庫奔潰
- 應用服務器奔潰
- 重啓應用服務器無效
- Redis服務器奔潰
- Redis集羣奔潰
- 重啓數據庫後再次被瞬間的流量放倒
- 問題排查
- 在一個較短的時間內，緩存中較多的key集中過期
- 此週期內請求訪問過期的數據，redis未命中，redis向數據庫獲取數據
- 數據庫同時接受到大量的請求無法及時處理
- redis大量請求被積壓，開始出現超時現象
- 數據庫流量激增，數據庫奔潰
- 重啓後仍然面對緩存中無數據可用
- Redis服務器資源被嚴重佔用，redis服務器奔潰
- Redis集羣呈現奔潰，集羣瓦解
- 應用服務器無法及時得到數據響應請求，來自客戶端的請求數量越來越多，應用服務器奔潰
- 應用服務器，redis，數據庫全部重啓，效果不理想
- 解決方案（道）
- 更多的頁面靜態化處理
- 構建多級緩存架構
- Nginx緩存+redis緩存+ehcache緩存
- 檢測mysql嚴重耗時業務進行優化
對數據庫的瓶頸排查：例如超時查詢、耗時較高事務等
- 災難預警機制
- 監控redis服務器性能指標
Cpu佔用、cpu使用率
內存容量
查詢平均響應時間
線程數
- 限流、降級
- 短時間範圍內犧牲一些客戶體驗，限制一部分請求訪問，降低應用服務器壓力，待業務低速運轉後再逐步放開訪問
- 解決方案（術）
- 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秒，最高5分鐘
- 白名單策略
提前預熱各種分類數據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數據緩存階段，每次訪問數據庫，導致對數據庫服務器造成壓力。通過此類數據的出現量是一個較低的值，當出現此類情況以毒攻毒，並及時報警。應對策略應該在臨時預案防範方面多做文章。
無論是黑名單還是白名單，都是對整理系統的壓力，警報解除後儘快移除。