當資料量過大，主從之間資料量過大、資料同步過多時可能會發生宕機情況。尤其是在redis服務啟動時。
解決方案
前置工作：
準備工作：
實施：總結
快取預熱就是系統啟動前，將相關的快取資料載入到快取中。避免使用者先查詢資料庫，然後再將資料快取的情況。使用者直接從快取中得到資料。
資料庫服務崩潰過程
系統平穩執行中，資料庫連線量激增
應用伺服器無法及時處理請求
大量408、500錯誤出現
使用者反覆重新整理頁面，獲取資料
資料庫崩潰
應用服務崩潰
應用服務重啟無效
redis伺服器崩潰
redis集群崩潰
重啟資料庫後再次被瞬間流量放倒
問題分析
當短時間內redis大量key過期，應用伺服器向快取請求資料時，沒有命中，然後向資料庫查詢。造成資料庫訪問量激增，資料庫無法處理這麼多的請求。從而引發一系列錯誤。
解決方案1
總結
快取雪崩就是key集中時間過期，造成資料庫訪問量過大。如果能有效避免key過期時間集中，可有效避免快取雪崩現象。配合其他的策略一起使用，監控伺服器效能指標。
資料庫崩潰過程
系統平穩執行中資料庫訪問量激增
redis服務無大量key過期
redis服務平穩，無波動
資料庫崩潰
問題分析
redis某個key過期，該key的訪問量巨大，redis未命中。短時間內大量的請求資料庫，造成資料庫崩潰。
單個key高熱資料，key過期。
解決方案
總結
快取擊穿就是單個高熱key過期，redis未命中，短時間造成資料庫訪問量激增，從而使資料庫崩潰。應對策略應在業務資料分析與預先設定方面進行，配合監控測試與及時調整策略。仿照快取雪崩應對策略即可。
資料庫崩潰過程
系統平穩執行中
應用伺服器流量較大
redis伺服器命中率隨時間逐步降低
redis記憶體平穩，無記憶體壓力
redis伺服器cpu占用激增
資料庫服務壓力激增
資料庫崩潰
問題分析
redis中大面積出現未命中
出現非正常url訪問
解決方案
快取null
對查詢結果為null的資料進行快取（長期使用，定期清理），設定短時限，例如30-60秒，最高5分鐘
白名單策略
提前預熱各種分類資料id對應的bitmaps，id作為bitmaps的offset，相當於設定了資料白名單。當載入正常資料時，放
行，載入異常資料時直接攔截（效率偏低）
使用布隆過濾器（有關布隆過濾器的命中問題對當前狀況可以忽略）
實施監控
實時監控redis命中率（業務正常範圍時，通常會有乙個波動值）與null資料的佔比
------ 非活動時段波動：通常檢測3-5倍，超過5倍納入重點排查物件
------ 活動時段波動：通常檢測10-50倍，超過50倍納入重點排查物件
根據倍數不同，啟動不同的排查流程。然後使用黑名單進行防控（運營）
key加密
問題出現後，臨時啟動防災業務key，對key進行業務層傳輸加密服務，設定校驗程式，過來的key校驗
例如每天隨機分配60個加密串，挑選2到3個，混淆到頁面資料id中，發現訪問key不滿足規則，駁回資料訪問
Redis 企業級解決方案
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料緩 存的問題！使用者直接查詢事先被預熱的快取資料！大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時db請求量大 壓力驟增，引起雪崩 解決方案 可以給快取設定過期時...
Redis 企業級解決方案
目錄快取雪崩 快取擊穿 快取穿透 效能指標監控 伺服器啟動後迅速宕機 請求數量較高 主從之間資料吞吐量較大，資料同步操作頻度較高 前置準備工作 日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料 利用 lru 資料刪除策略，構建資料留存佇列，例如 strom 與 kafka 配合 準備工作 將統計...
Redis學習 14 企業級解決方案
系統執行過程中，突然資料庫連線量暴增，資料庫崩潰，應用伺服器崩潰，重啟應用伺服器無效，redis伺服器和集群崩潰，資料庫重啟後再次被瞬間流量放倒。在乙個較短的時間內，快取中較多的key集中過期。key過期後，開始直接請求資料庫，資料庫無法及時處理。redis請求開始積壓，出現請求超時。請求積累到一定...