Redis 雪崩

緩存層承載著大量的請求，有效保護了存儲層。但是如果由于緩存大量失效或者緩存整體不能提供服務(wù)，導(dǎo)致大量的請求到達存儲層，會使存儲層負載增加，這就是緩存雪崩的場景。

解決緩存雪崩，可以從以下幾個方面入手。

1.保持緩存層的高可用性

使用Redis 哨兵模式或者Redis 集群部署方式，即便個別Redis 節(jié)點下線，整個緩存層依然可以使用。除此之外，還可以在多個機房部署 Redis，這樣即便是機房死機，依然可以實現(xiàn)緩存層的高可用。

2.限流降級組件

無論是緩存層還是存儲層都會有出錯的概率，可以將它們視為資源。作為并發(fā)量較大的分布式系統(tǒng)，假如有一個資源不可用，可能會造成所有線程在獲取這個資源時異常，造成整個系統(tǒng)不可用。降級在高并發(fā)系統(tǒng)中是非常正常的，比如推薦服務(wù)中，如果個性化推薦服務(wù)不可用，可以降級補充熱點數(shù)據(jù)，不至于造成整個推薦服務(wù)不可用。常見的限流降級組件如 Hystrix、Sentinel 等。

3.緩存不過期

Redis 中保存的 key 永不失效，這樣就不會出現(xiàn)大量緩存同時失效的問題，但是隨之而來的就是Redis 需要更多的存儲空間。

4.優(yōu)化緩存過期時間

設(shè)計緩存時，為每一個 key 選擇合適的過期時間，避免大量的 key 在同一時刻同時失效，造成緩存雪崩。

5.使用互斥鎖重建緩存

在高并發(fā)場景下，為了避免大量的請求同時到達存儲層查詢數(shù)據(jù)、重建緩存，可以使用互斥鎖控制，如根據(jù) key 去緩存層查詢數(shù)據(jù)，當(dāng)緩存層為命中時，對 key 加鎖，然后從存儲層查詢數(shù)據(jù)，將數(shù)據(jù)寫入緩存層，最后釋放鎖。若其他線程發(fā)現(xiàn)獲取鎖失敗，則讓線程休眠一段時間后重試。對于鎖的類型，如果是在單機環(huán)境下可以使用 Java 并發(fā)包下的 Lock，如果是在分布式環(huán)境下，可以使用分布式鎖（Redis 中的 SETNX 方法）。

分布式環(huán)境下使用Redis 分布式鎖實現(xiàn)緩存重建，優(yōu)點是設(shè)計思路簡單，對數(shù)據(jù)一致性有保障;缺點是代碼復(fù)雜度增加，有可能會造成用戶等待。假設(shè)在高并發(fā)下，緩存重建期間 key 是鎖著的，如果當(dāng)前并發(fā) 1000 個請求，其中 999 個都在阻塞，會導(dǎo)致 999 個用戶請求阻塞而等待。

6.異步重建緩存

在這種方案下構(gòu)建緩存采取異步策略，會從線程池中獲取線程來異步構(gòu)建緩存，從而不會讓所有的請求直接到達存儲層，該方案中每個Redis key 維護邏輯超時時間，當(dāng)邏輯超時時間小于當(dāng)前時間時，則說明當(dāng)前緩存已經(jīng)失效，應(yīng)當(dāng)進行緩存更新，否則說明當(dāng)前緩存未失效，直接返回緩存中的 value 值。如在Redis 中將 key 的過期時間設(shè)置為 60 min，在對應(yīng)的 value 中設(shè)置邏輯過期時間為 30 min。這樣當(dāng) key 到了 30 min 的邏輯過期時間，就可以異步更新這個 key 的緩存，但是在更新緩存的這段時間內(nèi)，舊的緩存依然可用。這種異步重建緩存的方式可以有效避免大量的 key 同時失效。

　　來源：今日頭條（）IT技術(shù)分享?