Redis 擊穿、穿透、雪崩產(chǎn)生原因以及解決思路
大家都知道,計(jì)算機(jī)的瓶頸之一就是IO,為了解決內(nèi)存與磁盤速度不匹配的問(wèn)題,產(chǎn)生了緩存,將一些熱點(diǎn)數(shù)據(jù)放在內(nèi)存中,隨用隨取,降低連接到數(shù)據(jù)庫(kù)的請(qǐng)求鏈接,避免數(shù)據(jù)庫(kù)掛掉。需要注意的是,無(wú)論是擊穿還是后面談到的穿透與雪崩,都是在高并發(fā)前提下,比如當(dāng)緩存中某一個(gè)熱點(diǎn)key失效。
問(wèn)題起因
有兩個(gè)主要原因:
- Key過(guò)期;
- Key被頁(yè)面置換淘汰。
對(duì)于第一個(gè)原因是因?yàn)樵赗edis中,Key有過(guò)期時(shí)間,如果某一個(gè)時(shí)刻(假如商城做活動(dòng),零點(diǎn)開(kāi)始)key失效,那么零點(diǎn)之后對(duì)某一個(gè)商品查詢請(qǐng)求將全都?jí)旱綌?shù)據(jù)庫(kù)上,導(dǎo)致數(shù)據(jù)庫(kù)崩。
對(duì)于第二個(gè)原因,因?yàn)閮?nèi)存是有限的,要時(shí)時(shí)刻刻緩存新的數(shù)據(jù),淘汰舊的數(shù)據(jù),所以在一定的頁(yè)面置換策略(常見(jiàn)頁(yè)面置換算法圖解)中,淘汰數(shù)據(jù),如果某些商品做活動(dòng)之前無(wú)人問(wèn)津,勢(shì)必會(huì)被淘汰。
應(yīng)對(duì)擊穿的處理思路
正常的處理請(qǐng)求如圖:
由于key過(guò)期在所難免,高流量來(lái)到Redis時(shí),根據(jù)Redis的單線程特性,可以認(rèn)為任務(wù)是在隊(duì)列里依次執(zhí)行的,當(dāng)請(qǐng)求到達(dá)Redis發(fā)現(xiàn)Key過(guò)期時(shí),進(jìn)行一個(gè)操作:設(shè)置鎖。
這個(gè)流程大概如下:
- 請(qǐng)求到達(dá)Redis,發(fā)現(xiàn)Redis Key過(guò)期,查看有沒(méi)有鎖,沒(méi)有鎖的話回到隊(duì)列后面排隊(duì)
- 設(shè)置鎖,注意,這兒應(yīng)該是setnx(),而不是set(),因?yàn)榭赡苡衅渌€程已經(jīng)設(shè)置鎖了
- 獲取鎖,拿到鎖了就去數(shù)據(jù)庫(kù)取數(shù)據(jù),請(qǐng)求返回后釋放鎖。
但是引出了一個(gè)新的問(wèn)題,如果拿到鎖去拿數(shù)據(jù)的請(qǐng)求然后掛了怎么辦?也就是鎖沒(méi)有釋放,其他進(jìn)程都在等鎖,解決辦法是:
對(duì)鎖設(shè)置一個(gè)過(guò)期時(shí)間,如果到達(dá)了過(guò)期時(shí)間還沒(méi)釋放就自動(dòng)釋放,問(wèn)題又來(lái)了,鎖掛了好說(shuō),但是如果是鎖超時(shí)呢?也就是在設(shè)定的時(shí)間里數(shù)據(jù)沒(méi)有取出來(lái),但是鎖由過(guò)期了,常見(jiàn)的思路是,鎖過(guò)期時(shí)間值遞增,但是想想不靠譜,因?yàn)榈谝粋€(gè)請(qǐng)求可能超時(shí),如果后面的也超時(shí)呢,接連多次超時(shí)之后,鎖過(guò)期時(shí)間值勢(shì)必特別大了,這樣做弊端太多。
另外一個(gè)思路是,再開(kāi)啟一個(gè)線程,進(jìn)行監(jiān)控,如果取數(shù)據(jù)的線程沒(méi)有掛的話,就適當(dāng)延遲鎖的過(guò)期時(shí)間。
穿透
穿透主要原因是很多請(qǐng)求都在訪問(wèn)數(shù)據(jù)庫(kù)不存在的數(shù)據(jù),例如一個(gè)賣書的商城一直被請(qǐng)求查詢茶葉產(chǎn)品,由于Redis緩存主要是用來(lái)緩存熱點(diǎn)數(shù)據(jù),對(duì)于數(shù)據(jù)庫(kù)都不存在的數(shù)據(jù),是沒(méi)法緩存的,這種異常流量就會(huì)直接到達(dá)數(shù)據(jù)庫(kù)并且返回"沒(méi)有"的查詢結(jié)果。
應(yīng)對(duì)這種請(qǐng)求,處理辦法是對(duì)訪問(wèn)請(qǐng)求加一層過(guò)濾器,例如布隆過(guò)濾器、增強(qiáng)版布隆過(guò)濾器、布谷鳥(niǎo)過(guò)濾器。
除了布隆過(guò)濾器,可以增加一些參數(shù)檢驗(yàn),例如數(shù)據(jù)庫(kù)數(shù)據(jù)id一般都是遞增的,如果請(qǐng)求 id = -10 這種參數(shù),勢(shì)必繞過(guò)Redis,避免這種情況,可以對(duì)用戶真實(shí)性檢驗(yàn)等操作。
雪崩
雪崩,和擊穿類似,不同的是擊穿是一個(gè)熱點(diǎn)Key某時(shí)刻失效,而雪崩是大量的熱點(diǎn)Key在一瞬間失效,網(wǎng)絡(luò)上很多博客都在強(qiáng)調(diào)解決雪崩的策略是隨機(jī)過(guò)期時(shí)間,這個(gè)非常不準(zhǔn)確,舉個(gè)例子,銀行做活動(dòng),之前這個(gè)利息系數(shù)為2%,過(guò)了零點(diǎn)系數(shù)改為3%,這種情況能將用戶的對(duì)應(yīng)的key改為隨機(jī)過(guò)期嗎?如果用的過(guò)去的數(shù)據(jù)叫臟數(shù)據(jù)。
明顯不可以,同樣存錢,你存到年底利息300萬(wàn),隔壁才200萬(wàn),這不得打架啊,開(kāi)玩笑。
正確的思路是,首先要看看這個(gè)Key過(guò)期是不是時(shí)點(diǎn)性有關(guān),時(shí)點(diǎn)性無(wú)關(guān)的話,可以隨機(jī)過(guò)期時(shí)間解決。
如果是時(shí)點(diǎn)性有關(guān),例如剛剛說(shuō)的銀行某一天改變某系數(shù),那么就要利用強(qiáng)依賴擊穿方案,策略是先過(guò)去的線程更新一下所有key。
在后臺(tái)更新熱點(diǎn)key的同時(shí),業(yè)務(wù)層將進(jìn)來(lái)的請(qǐng)求延時(shí)一下,例如短暫的睡幾毫秒或者秒,給后面的更新熱點(diǎn)key分散壓力。