淺談Redis緩存雪崩解決方案
緩存層承載著大量的請求,有效保護了存儲層。但是如果由于大量緩存失效或者緩存整體不能提供服務,導致大量的請求到達存儲層,會使存儲層負載增加(大量的請求查詢數據庫) 。這就是緩存雪崩的場景;
解決緩存雪崩可以從下面的幾點著手:
1.保持緩存層的高可用
使用Redis哨兵模式或者Redis集群部署方式,即是個別Redis節(jié)點下線,整個緩存層依然可以使用。除此之外還可以在多個機房部署Redis,這樣即便是機房死機,依然可以實現緩存層的高可用。
2.限流降級組件
無論是緩存層還是存儲層都會有出錯的概率,可以將它們視為資源。作為并發(fā)量較大的分布式系統(tǒng),假如有一個資源不可用,可能會造成所有線程在獲取這個資源時異常,造成整個系統(tǒng)不可用。降級在高并發(fā)系統(tǒng)中是非常正常的,比如推薦服務中,如果個性化推薦服務不可用,可以降級補充熱點數據,不至于造成整個推薦服務不可用。常見的限流降級組件如 Hystrix、Sentinel 等。
3.緩存不過期
Redis 中保存的 key 永不失效,這樣就不會出現大量緩存同時失效的問題,但是隨之而來的就是Redis 需要更多的存儲空間。
4.優(yōu)化緩存過期時間
設計緩存時,為每一個 key 選擇合適的過期時間,避免大量的 key 在同一時刻同時失效,造成緩存雪崩。
5.使用互斥鎖重建緩存
在高并發(fā)場景下,為了避免大量的請求同時到達存儲層查詢數據、重建緩存,可以使用互斥鎖控制,如根據 key 去緩存層查詢數據,當緩存層為命中時,對 key 加鎖,然后從存儲層查詢數據,將數據寫入緩存層,最后釋放鎖。若其他線程發(fā)現獲取鎖失敗,則讓線程休眠一段時間后重試。對于鎖的類型,如果是在單機環(huán)境下可以使用 Java 并發(fā)包下的 Lock,如果是在分布式環(huán)境下,可以使用分布式鎖(Redis 中的 SETNX 方法)。
分布式環(huán)境下互斥鎖重建緩存?zhèn)未a
/** * 互斥鎖建立緩存 * **/ public String get(String key) { // redis中查詢key對應的value String value = redis.get(key); // 緩存未命中 if (value == null) { // 互斥鎖 String key_mutex_lock = "mutex:lock" + key; // 互斥鎖加鎖成功 if(redis.setnx(key_mutex_lock,"1")) { // 返回 0(false),1(true) try { // 設置互斥鎖超時時間,這里設置的是鎖的失效時間,而不是key的失效時間 redis.expire(key_mutex_lock,3*60); // 從數據庫查詢 value = db.get(key); // 數據寫入緩存 redis.set(key,value); } finally { // 釋放鎖 boolean keyExist = jedis.exists(key_mutex_lock); if(keyExist){ redis.delete(key_mutex_lock); } } else { // 加鎖失敗,線程休息50ms后重試 Thread.sleep(50); return get(key); // 直接返回緩存結果 } } }
分布式環(huán)境下使用Redis 分布式鎖實現緩存重建,優(yōu)點是設計思路簡單,對數據一致性有保障;缺點是代碼復雜度增加,有可能會造成用戶等待。假設在高并發(fā)下,緩存重建期間 key 是鎖著的,如果當前并發(fā) 1000 個請求,其中 999 個都在阻塞,會導致 999 個用戶請求阻塞而等待。
6.異步重建緩存
在這種方案下構建緩存采取異步策略,會從線程池中獲取線程來異步構建緩存,從而不會讓所有的請求直接到達存儲層,該方案中每個Redis key 維護邏輯超時時間,當邏輯超時時間小于當前時間時,則說明當前緩存已經失效,應當進行緩存更新,否則說明當前緩存未失效,直接返回緩存中的 value 值。如在Redis 中將 key 的過期時間設置為 60 min,在對應的 value 中設置邏輯過期時間為 30 min。這樣當 key 到了 30 min 的邏輯過期時間,就可以異步更新這個 key 的緩存,但是在更新緩存的這段時間內,舊的緩存依然可用。這種異步重建緩存的方式可以有效避免大量的 key 同時失效。
/** * 異步重建緩存: ValueObject為對應的封裝的實體模型 * **/ public String get(String key) { // 重緩存中查詢key對應的ValueObject對象 ValueObject valueObject = redis.get(key); // 獲取存儲中對應的value值 String value = valueObject.getValue(); // 獲取實體模型中的緩存過期的時間:timeOut = 設置緩存時的當前時間+過期時間(如30秒,60秒等等) long logicTimeOut = valueObject.getTimeOut(); // 等位換算為long類型 // 當前可以在邏輯上失效 if (logicTimeOut <= System.currentTimeMillis()) { // 異步更新緩存 threadPool.execute(new Runnable() { String key_mutex_lock = "mutex_lock" + key; // 互斥鎖加鎖成功 if(redis.setnx(key_mutex_lock,"1")) { // 返回 0(false),1(true) try { // 設置互斥鎖超時時間,這里設置的是鎖的失效時間,而不是key的失效時間 redis.expire(key_mutex_lock,3*60); // 從數據庫查詢 dbValue = db.get(key); // 數據寫入緩存 redis.set(key,dbValue); } finally { // 釋放鎖 boolean keyExist = jedis.exists(key_mutex_lock); if(keyExist){ redis.delete(key_mutex_lock); } } } else { } }); return value; // 直接返回緩存結果 } }
到此這篇關于淺談Redis緩存雪崩解決方案的文章就介紹到這了,更多相關Redis緩存雪崩內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
使用Redis存儲SpringBoot項目中Session的詳細步驟
在開發(fā)Spring Boot項目時,我們通常會遇到如何高效管理Session的問題,默認情況下,Spring Boot會將Session存儲在內存中,今天,我們將學習如何將Session存儲從內存切換到Redis,并驗證配置是否成功,需要的朋友可以參考下2024-06-06