目錄快取雪崩
快取擊穿
快取穿透
效能指標監控
伺服器啟動後迅速宕機
請求數量較高
主從之間資料吞吐量較大，資料同步操作頻度較高
前置準備工作：
日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料
利用 lru 資料刪除策略，構建資料留存佇列，例如：strom 與 kafka 配合
準備工作：
將統計結果中的資料分類，根據級別，redis 優先載入級別較高的熱點資料
利用分布式多伺服器同時進行資料讀取，提速資料載入過程
實施：使用指令碼程式固定觸發資料預熱過程
如果條件允許，使用了 cdn（內容分發網路），效果會更好
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查資料庫，然後再將資料快取的問題，使用者直接查詢事先被預熱的快取資料。
系統平穩執行過程中，忽然資料庫連線量激增
應用伺服器無法及時處理請求
大量 408，500 錯誤頁面出現
客戶反覆重新整理頁面獲取資料
資料庫崩潰
應用伺服器崩潰
重啟應用伺服器無效
redis 伺服器崩潰
redis 集群崩潰
重啟資料庫後再次被瞬間流量放倒
在乙個較短的時間內，快取中較多的key集中過期
此週期內請求訪問過期的資料，redis 未命中，redis 向資料庫獲取資料
資料庫同時接收到大量的請求無法及時處理
redis 大量請求被積壓，開始出現超時現象
資料庫流量激增，資料庫崩潰
重啟後仍然面對快取中無資料可用
redis 伺服器資源被嚴重占用，redis 伺服器崩潰
redis 集群呈現崩塌，集群瓦解
應用伺服器無法及時得到資料庫響應請求，來自客戶端的請求數量越來越多，應用伺服器崩潰
應用伺服器，redis，資料庫全部重啟，效果不理想
更多的頁面靜態化處理
構建多級快取架構
檢測 mysql 嚴重耗時業務進行優化
災難預警機制
監控 redis 伺服器效能指標
限流、降級
短時間範圍內犧牲一些客戶體驗，限制一部分請求訪問，降低應用伺服器壓力，待業務低速運轉後再逐步放開訪問
lru 與 lfu 切換
資料有效期策略調整
超熱資料使用永久 key
定期維護（自動 + 人工）
對即將過期資料做訪問量分析，確認是否延時，配合訪問量統計，做熱點資料的延時
加鎖 慎用！
快取雪崩就是瞬間過期資料量太大，導致對資料庫伺服器造成壓力。如能夠有效避免過期時間集中，可以有效解決雪崩現象的出現（約40%），配合其他策略一起使用，並監控伺服器的執行資料，根據執行記錄做快速調整
系統平穩執行過程中，資料庫連線量瞬間激增
redis 伺服器無大量 key 過期
redis 記憶體平穩，無波動
redis 伺服器 cpu 正常
資料庫崩潰
redis 中某個 key 過期，該 key 訪問量巨大
多個資料請求從伺服器直接壓到 redis 後，均未命中
redis 在短時間內發起了大量對資料庫中同一資料的訪問
預先設定
以電商為例，每個商家根據店鋪等級，指定若干款主打商品，在購物節期間，加大此類資訊 key 的過期時長，注意：購物節不僅僅指當天，以及後續若干天，訪問峰值呈現逐漸降低的趨勢
現場調整
監控訪問量，對自然流量激增的資料延長過期時間或設定為永久性 key
後台重新整理資料
後台定時任務，高峰期來臨之前，重新整理資料有效期，確保不丟失
二級快取
設定不同的失效時間，保障不會被同時淘汰就行
加鎖 分布式鎖，防止被擊穿，但是要注意也是效能瓶頸，慎重！
快取擊穿就是單個高熱資料過期的瞬間，資料訪問量較大，未命中 redis 後，發起了大量對同一資料的資料庫訪問，導致對資料庫伺服器造成壓力。應對策略應該在業務資料分析與預防方面進行，配合執行監控測試與即時調整策略，畢竟單個 key 的過期監控難度較高，配合雪崩處理策略即可。
系統平穩執行過程中，應用伺服器流量隨時間增量較大
redis 伺服器命中率隨時間逐步降低
redis 記憶體平穩，記憶體無壓力
redis 伺服器 cpu 占用激增
資料庫伺服器壓力激增
資料庫崩潰
redis 中大面積出現未命中
出現非正常 url 訪問
快取 null
對查詢結果為 null 的資料進行快取（長期使用，定期清理），設定短時期，例如30~60s，最高5分鐘
白名單策略
實施監控
實時監控 redis 命中率（業務正常範圍時，通常會有乙個波動值）與 null 資料的佔比
根據倍數不同，啟動不同的排查流程。然後使用黑名單進行防控（運營）
key 加密
問題出現後，臨時啟動防災業務 key，對 key 進行業務層傳輸加密服務，設定校驗程式，過來的 key 校驗。
例如每天隨機分配 60 個加密串，挑選2~3個，混淆到頁面資料 id 中，發現訪問 key 不滿足規則，駁回資料訪問
快取擊穿訪問了不存在的資料，跳過了合法資料的 redis 資料快取階段，每次訪問資料庫，導致對資料庫伺服器造成壓力。通常此類資料的出現量是乙個較低的值，當出現此類情況以毒攻毒，並及時報警。應對策略應該在臨時預案防範方面做文章。
無論是黑名單還是白名單，都是對整體系統的壓力，警報解除後盡快移除。
命令相關配置
slowlog-log-slower-than 1000 # 設定慢查詢的時間下線，單位：微秒
slowlog-max-len 100 # 設定慢查詢命令對應的日誌顯示長度，單位：命令數
Redis 企業級解決方案
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料緩 存的問題！使用者直接查詢事先被預熱的快取資料！大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時db請求量大 壓力驟增，引起雪崩 解決方案 可以給快取設定過期時...
Redis學習 14 企業級解決方案
系統執行過程中，突然資料庫連線量暴增，資料庫崩潰，應用伺服器崩潰，重啟應用伺服器無效，redis伺服器和集群崩潰，資料庫重啟後再次被瞬間流量放倒。在乙個較短的時間內，快取中較多的key集中過期。key過期後，開始直接請求資料庫，資料庫無法及時處理。redis請求開始積壓，出現請求超時。請求積累到一定...
Redis學習 14 企業級解決方案
系統平穩執行過程中，資料庫連線量瞬間激增，但是沒有大量key過期，redis記憶體平穩，redis伺服器cpu正常。某乙個熱點key過期了，這個key訪問量巨大，導致大量請求在redis沒拿到資料，直接從資料庫拿，導致資料庫崩潰。預先設定。對於一些可以 到的熱點資料，延長過期時間。現場調整。監控訪問...