Redis 雪崩

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

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

[[275329]]

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

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

2.限流降級(jí)組件

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

3.緩存不過(guò)期

Redis 中保存的 key 永不失效，這樣就不會(huì)出現(xiàn)大量緩存同時(shí)失效的問(wèn)題，但是隨之而來(lái)的就是Redis 需要更多的存儲(chǔ)空間。

4.優(yōu)化緩存過(guò)期時(shí)間

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

5.使用互斥鎖重建緩存

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

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

6.異步重建緩存

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