Redis緩存預熱和緩存雪崩問題怎樣解決？

緩存預熱

場景：“宕機”

服務(wù)器啟動后迅速宕機

問題排查：

1.請求數(shù)量較高，大量的請求過來之后都需要去從緩存中獲取數(shù)據(jù)，但是緩存中又沒有，此時從數(shù)據(jù)庫中查找數(shù)據(jù)然后將數(shù)據(jù)再存入緩存，造成了短期內(nèi)對redis的高強度操作從而導致問題

2.主從之間數(shù)據(jù)吞吐量較大，數(shù)據(jù)同步操作頻度較高

解決方案：

前置準備工作：

1.日常例行統(tǒng)計數(shù)據(jù)訪問記錄，統(tǒng)計訪問頻度較高的熱點數(shù)據(jù)

2.利用LRU數(shù)據(jù)刪除策略，構(gòu)建數(shù)據(jù)留存隊列例如：storm與kafka配合

準備工作：

1.將統(tǒng)計結(jié)果中的數(shù)據(jù)分類，根據(jù)級別，redis優(yōu)先加載級別較高的熱點數(shù)據(jù)

2.利用分布式多服務(wù)器同時進行數(shù)據(jù)讀取，提速數(shù)據(jù)加載過程

3.熱點數(shù)據(jù)主從同時預熱

實施：

4.使用腳本程序固定觸發(fā)數(shù)據(jù)預熱過程

5.如果條件允許，使用了CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))，效果會更好

總的來說：緩存預熱就是系統(tǒng)啟動前，提前將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。避免在用戶請求的時候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題!用戶直接查詢事先被預熱的緩存數(shù)據(jù)!

緩存雪崩

場景：數(shù)據(jù)庫服務(wù)器崩潰，一連串的場景會隨之兒來。

1.系統(tǒng)平穩(wěn)運行過程中，忽然數(shù)據(jù)庫連接量激增

2.應(yīng)用服務(wù)器無法及時處理請求

3.大量408，500錯誤頁面出現(xiàn)

4.客戶反復刷新頁面獲取數(shù)據(jù)

5.數(shù)據(jù)庫崩潰

6.應(yīng)用服務(wù)器崩潰

7.重啟應(yīng)用服務(wù)器無效

8.Redis服務(wù)器崩潰

9.Redis集群崩潰

10.重啟數(shù)據(jù)庫后再次被瞬間流量放倒

問題排查：

1.在一個較短的時間內(nèi)，緩存中較多的key集中過期

2.此周期內(nèi)請求訪問過期的數(shù)據(jù)，redis未命中，redis向數(shù)據(jù)庫獲取數(shù)據(jù)

3.數(shù)據(jù)庫同時接收到大量的請求無法及時處理

4.Redis大量請求被積壓，開始出現(xiàn)超時現(xiàn)象

5.數(shù)據(jù)庫流量激增，數(shù)據(jù)庫崩潰

6.重啟后仍然面對緩存中無數(shù)據(jù)可用

7.Redis服務(wù)器資源被嚴重占用，Redis服務(wù)器崩潰

8.Redis集群呈現(xiàn)崩塌，集群瓦解

9.應(yīng)用服務(wù)器無法及時得到數(shù)據(jù)響應(yīng)請求，來自客戶端的請求數(shù)量越來越多，應(yīng)用服務(wù)器崩潰

10.應(yīng)用服務(wù)器，redis，數(shù)據(jù)庫全部重啟，效果不理想

總而言之就兩點：短時間范圍內(nèi)，大量key集中過期

解決方案

思路：

1.更多的頁面靜態(tài)化處理

2.構(gòu)建多級緩存架構(gòu)：Nginx緩存+redis緩存+ehcache緩存

3.檢測Mysql嚴重耗時業(yè)務(wù)進行優(yōu)化：對數(shù)據(jù)庫的瓶頸排查：例如超時查詢、耗時較高事務(wù)等

4.災難預警機制：? 監(jiān)控redis服務(wù)器性能指標，CPU占用、CPU使用率，內(nèi)存容量，查詢平均響應(yīng)時間和線程數(shù)

5.限流、降級

短時間范圍內(nèi)犧牲一些客戶體驗，限制一部分請求訪問，降低應(yīng)用服務(wù)器壓力，待業(yè)務(wù)低速運轉(zhuǎn)后再逐步放開訪問

落地實踐：

1.LRU與LFU切換

2.數(shù)據(jù)有效期策略調(diào)整?：根據(jù)業(yè)務(wù)數(shù)據(jù)有效期進行分類錯峰，A類90分鐘，B類80分鐘，C類70分鐘過期時間使用固定時間+隨機值的形式，稀釋集中到期的key的數(shù)量

3.超熱數(shù)據(jù)使用永久key

4.定期維護(自動+人工)：對即將過期數(shù)據(jù)做訪問量分析，確認是否延時，配合訪問量統(tǒng)計，做熱點數(shù)據(jù)的延時

5.加鎖：慎用!

總的來說：緩存雪崩就是瞬間過期數(shù)據(jù)量太大，導致對數(shù)據(jù)庫服務(wù)器造成壓力。如能夠有效避免過期時間集中，可以有效解決雪崩現(xiàn)象的 出現(xiàn)(約40%)，配合其他策略一起使用，并監(jiān)控服務(wù)器的運行數(shù)據(jù)，根據(jù)運行記錄做快速調(diào)整。