為什麼要進行快取預熱？
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
怎麼做？
前置準備工作：
日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料
利用lru資料刪除策略，構建資料留存佇列 例如：storm與kafka配合
準備工作：
將統計結果中的資料分類，根據級別，redis優先載入級別較高的熱點資料
利用分布式多伺服器同時進行資料讀取，提速資料載入過程
熱點資料主從同時預熱
實施：使用指令碼程式固定觸發資料預熱過程
如果條件允許，使用了cdn（內容分發網路），效果會更好
什麼是快取雪崩
快取雪崩就是瞬間過期資料量太大，後面的請求都直接落到了資料庫上，造成資料庫短時間內承受大量請求。如能夠有效避免過期時間集中，可以有效解決雪崩現象的出現 （約40%），配合其他策略一起使用，並監控伺服器的執行資料，根據執行記錄做快速調整。
怎麼解決
針對 redis 服務不可用的情況：
針對熱點快取失效的情況：
什麼是快取擊穿？
快取擊穿就是單個高熱資料過期的瞬間，資料訪問量較大，未命中redis後，發起了大量對同一資料的資料庫訪問，導致對資料庫伺服器造成壓力。
怎麼解決？
加大高熱資料的過期時長
監控訪問量，對自然流量激增的資料延長過期時長或設定為永久key
設計二級快取，二級快取中設定不同的過期時間保證不在同一時間過期
什麼是快取穿透？
快取穿透說簡單點就是大量請求的 key 根本不存在於快取中，導致請求直接到了資料庫上，根本沒有經過快取這一層。舉個例子：某個黑客故意製造我們快取中不存在的 key 發起大量請求，導致大量請求落到資料庫。
怎麼解決
最基本的就是首先做好引數校驗，一些不合法的引數請求直接丟擲異常資訊返回給客戶端
快取無效key
如果快取和資料庫都查不到某個 key 的資料就寫乙個到 redis 中去並設定過期時間，具體命令如下： set key value ex 10086 。這種方式可以解決請求的 key 變化不頻繁的情況，如果黑客惡意攻擊，每次構建不同的請求 key，會導致 redis 中快取大量無效的 key 。很明顯，這種方案並不能從根本上解決此問題。如果非要用這種方式來解決穿透問題的話，盡量將無效的 key 的過期時間設定短一點比如 1 分鐘。
使用布隆過濾器
把所有可能存在的請求的值都存放在布隆過濾器中，當使用者請求過來，先判斷使用者發來的請求的值是否存在於布隆過濾器中。不存在的話，直接返回請求引數錯誤資訊給客戶端，存在的話才會走下面的流程。但是布隆過濾器說某個元素存在，小概率會誤判。布隆過濾器說某個元素不在，那麼這個元素一定不在。
《不了解布隆過濾器？一文給你整的明明白白！》
Redis 企業級解決方案
快取預熱就是系統啟動前，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料緩 存的問題！使用者直接查詢事先被預熱的快取資料！大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時db請求量大 壓力驟增，引起雪崩 解決方案 可以給快取設定過期時...
Redis 企業級解決方案
目錄快取雪崩 快取擊穿 快取穿透 效能指標監控 伺服器啟動後迅速宕機 請求數量較高 主從之間資料吞吐量較大，資料同步操作頻度較高 前置準備工作 日常例行統計資料訪問記錄，統計訪問頻度較高的熱點資料 利用 lru 資料刪除策略，構建資料留存佇列，例如 strom 與 kafka 配合 準備工作 將統計...
Redis學習 14 企業級解決方案
系統執行過程中，突然資料庫連線量暴增，資料庫崩潰，應用伺服器崩潰，重啟應用伺服器無效，redis伺服器和集群崩潰，資料庫重啟後再次被瞬間流量放倒。在乙個較短的時間內，快取中較多的key集中過期。key過期後，開始直接請求資料庫，資料庫無法及時處理。redis請求開始積壓，出現請求超時。請求積累到一定...