緩存問(wèn)題

緩存雪崩

同一時(shí)間段內(nèi)大量的熱點(diǎn) key 全部過(guò)期或者 Redis 宕機(jī)，所有的請(qǐng)求都打到數(shù)據(jù)庫(kù)上

解決方法：

• 給不同的 key 添加不同的 TTL ；
• 利用 Redis 集群提高系統(tǒng)的可用性；
• 當(dāng)系統(tǒng)故障后，可以啟動(dòng)服務(wù)熔斷機(jī)制，暫停業(yè)務(wù)對(duì)外訪問(wèn)，直接返回錯(cuò)誤，不讓請(qǐng)求訪問(wèn)數(shù)據(jù)庫(kù)；

緩存穿透

客戶端請(qǐng)求的數(shù)據(jù)在 Redis 和 數(shù)據(jù)庫(kù) 中都不存在，這樣的緩存永遠(yuǎn)不會(huì)生效

解決方法：

• 限制非法的請(qǐng)求，對(duì)請(qǐng)求的參數(shù)作檢驗(yàn)
• 緩存空對(duì)象或默認(rèn)值
• 使用布隆過(guò)濾器快速判斷數(shù)據(jù)是否存在，避免通過(guò)查詢數(shù)據(jù)庫(kù)判斷數(shù)據(jù)是否存在

布隆過(guò)濾器

我們?cè)趯懭霐?shù)據(jù)庫(kù)時(shí)，在布隆過(guò)濾器中做一個(gè)標(biāo)記。業(yè)務(wù)線程確認(rèn)緩存失效后，去布隆過(guò)濾器中查詢?cè)撝凳欠翊嬖?，而不用去?shù)據(jù)庫(kù)中進(jìn)行查詢；

即使發(fā)生了緩存穿透，大量請(qǐng)求只會(huì)查詢 Redis 和布隆過(guò)濾器，而不會(huì)查詢數(shù)據(jù)庫(kù)，保證了數(shù)據(jù)庫(kù)能正常運(yùn)行，Redis 自身也是支持布隆過(guò)濾器的。

布隆過(guò)濾器由三個(gè)哈希函數(shù)，一個(gè)位圖數(shù)組組成：

• 布隆過(guò)濾器先將輸入的值通過(guò)三個(gè)哈希函數(shù)得到相應(yīng)的哈希值；
• 將哈希值對(duì)數(shù)組的長(zhǎng)度取模，進(jìn)而得到相應(yīng)的下標(biāo)；
• 將三個(gè)下標(biāo)設(shè)置為1；

判斷時(shí)，布隆過(guò)濾器會(huì)讀取輸入的值，并通過(guò)三個(gè)哈希函數(shù)轉(zhuǎn)化成三個(gè)數(shù)組下標(biāo)，然后若三個(gè)下標(biāo)對(duì)于值均為1，則該數(shù)據(jù)存在于布隆過(guò)濾器中，若有一個(gè)為0，則認(rèn)為該數(shù)據(jù)不存在布隆過(guò)濾器中；

所以，布隆過(guò)濾器說(shuō)存在數(shù)據(jù)，但實(shí)際上該數(shù)據(jù)可能不存在，布隆過(guò)濾器說(shuō)不存在該數(shù)據(jù)，則該數(shù)據(jù)真的不存在；

緩存擊穿

某一個(gè)熱點(diǎn) key 過(guò)期消失了，大量的請(qǐng)求打到數(shù)據(jù)庫(kù)上，數(shù)據(jù)庫(kù)很容易被沖垮；

解決方法：

• 使用互斥鎖來(lái)更新緩存。當(dāng)某個(gè)線程成功獲取鎖后，進(jìn)行從數(shù)據(jù)庫(kù)中讀取最新的數(shù)據(jù)，并把新數(shù)據(jù)存入緩存中去即可，而沒(méi)有獲取到鎖的線程進(jìn)行等待或者返回請(qǐng)求失敗的響應(yīng)即可；
• 不給熱點(diǎn)數(shù)據(jù)添加過(guò)期值，該 key 由我們手動(dòng)刪除；
• 可以在 value 中添加邏輯過(guò)期的字段，一旦超過(guò)該時(shí)間戳就返回舊的值，再去數(shù)據(jù)庫(kù)進(jìn)行更新；

緩存更新問(wèn)題

緩存更新策略

主動(dòng)更新

更新數(shù)據(jù)庫(kù)和更新緩存的順序問(wèn)題

• 先更新緩存，再更新數(shù)據(jù)庫(kù)

出現(xiàn)了數(shù)據(jù)的不一致，緩存中的數(shù)據(jù)為 b，而數(shù)據(jù)庫(kù)中的數(shù)據(jù)為 a

• 先更新數(shù)據(jù)庫(kù)，再更新緩存

出現(xiàn)了數(shù)據(jù)的不一致，數(shù)據(jù)庫(kù)中的值為 b，而緩存中的值為 a

所以，無(wú)論是「先更新數(shù)據(jù)庫(kù)，再更新緩存」，還是「先更新緩存，再更新數(shù)據(jù)庫(kù)」，這兩個(gè)方案都存在并發(fā)問(wèn)題，當(dāng)兩個(gè)請(qǐng)求并發(fā)更新同一條數(shù)據(jù)的時(shí)候，可能會(huì)出現(xiàn)緩存和數(shù)據(jù)庫(kù)中的數(shù)據(jù)不一致的現(xiàn)象。

更新數(shù)據(jù)庫(kù)和刪除緩存的順序問(wèn)題

這里我們更新數(shù)據(jù)時(shí)，不在更新緩存，而是刪除緩存，當(dāng)讀取不到緩存時(shí)，先從數(shù)據(jù)庫(kù)中讀取，再寫入緩存；這種叫做旁路緩存策略

寫操作：

• 更新數(shù)據(jù)庫(kù)
• 刪除緩存

讀操作：

• 如果命中了緩存，直接返回?cái)?shù)據(jù)
• 如果沒(méi)有命中緩存，則從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)，再寫入緩存

• 先刪除緩存，再更新數(shù)據(jù)庫(kù)

此時(shí)也出現(xiàn)了數(shù)據(jù)的不一致，緩存中的數(shù)據(jù)為 a，數(shù)據(jù)庫(kù)中的數(shù)據(jù)為 b

• 先更新數(shù)據(jù)庫(kù)，再刪除緩存

此時(shí)也出現(xiàn)了數(shù)據(jù)的不一致，緩存中的數(shù)據(jù)為 a，數(shù)據(jù)庫(kù)中的數(shù)據(jù)為 b

但是這種方式出現(xiàn)的幾率會(huì)很低，因?yàn)楦戮彺?a 這步操作是在Redis中進(jìn)行的，更新數(shù)據(jù)庫(kù)為 b 的操作是在數(shù)據(jù)庫(kù)中進(jìn)行的，Redis 中的寫入操作比 數(shù)據(jù)庫(kù)中的寫入操作會(huì)快很多，所以我們一般采用 更新數(shù)據(jù)庫(kù) + 刪除緩存 的手段

如果強(qiáng)制保存緩存為最新值，可以為緩存的 key 設(shè)置過(guò)期時(shí)間，如給 a 設(shè)置過(guò)期時(shí)間，可以作為兜底措施

• 延遲雙刪，針對(duì) 先刪除緩存，再更新數(shù)據(jù)庫(kù)的情況

偽代碼

刪除緩存 	delete(x)
更新數(shù)據(jù) 	update(x)
睡眠     	sleep(N)
再次刪除緩存	delete(x)

前提是：睡眠的時(shí)間要比讀請(qǐng)求的過(guò)程要大，保證讀請(qǐng)求寫入的緩存要在再次刪除緩存之前，不然再次刪除緩存后還會(huì)把舊的值寫入緩存

到此這篇關(guān)于Redis 常見(jiàn)緩存問(wèn)題總結(jié)的文章就介紹到這了,更多相關(guān)Redis 緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論