Redis擊穿穿透雪崩產(chǎn)生原因分析及解決思路面試

更新時間：2022年03月09日 10:14:52 作者：Q.E.D

這篇文章主要為大家介紹了Redis擊穿穿透雪崩產(chǎn)生原因及解決思路的面試問題答案參考，有需要的朋友可以借鑒參考下，希望能夠有所幫助祝大家多多進步

1、前言

大家都知道，計算機的瓶頸之一就是IO，為了解決內存與磁盤速度不匹配的問題，產(chǎn)生了緩存，將一些熱點數(shù)據(jù)放在內存中，隨用隨取，降低連接到數(shù)據(jù)庫的請求鏈接,避免數(shù)據(jù)庫掛掉。需要注意的是，無論是擊穿還是后面談到的穿透與雪崩,都是在高并發(fā)前提下，比如當緩存中某一個熱點key失效。

2、問題起因

有兩個主要原因：

1、Key過期；
2、Key被頁面置換淘汰。

對于第一個原因是因為在Redis中，Key有過期時間，如果某一個時刻(假如商城做活動,零點開始)key失效，那么零點之后對某一個商品查詢請求將全都壓到數(shù)據(jù)庫上，導致數(shù)據(jù)庫崩。

對于第二個原因，因為內存是有限的，要時時刻刻緩存新的數(shù)據(jù)，淘汰舊的數(shù)據(jù)，所以在一定的頁面置換策略(常見頁面置換算法圖解)中，淘汰數(shù)據(jù)，如果某些商品做活動之前無人問津，勢必會被淘汰。

3、應對擊穿的處理思路

正常的處理請求如圖：

由于key過期在所難免，高流量來到Redis時,根據(jù)Redis的單線程特性，可以認為任務是在隊列里依次執(zhí)行的，當請求到達Redis發(fā)現(xiàn)Key過期時，進行一個操作：設置鎖。

這個流程大概如下：

請求到達Redis，發(fā)現(xiàn)Redis Key過期，查看有沒有鎖，沒有鎖的話回到隊列后面排隊
設置鎖，注意，這兒應該是setnx()，而不是set()，因為可能有其他線程已經(jīng)設置鎖了
獲取鎖，拿到鎖了就去數(shù)據(jù)庫取數(shù)據(jù)，請求返回后釋放鎖。

但是引出了一個新的問題，如果拿到鎖去拿數(shù)據(jù)的請求然后掛了怎么辦?也就是鎖沒有釋放，其他進程都在等鎖，解決辦法是:

對鎖設置一個過期時間，如果到達了過期時間還沒釋放就自動釋放，問題又來了，鎖掛了好說，但是如果是鎖超時呢?也就是在設定的時間里數(shù)據(jù)沒有取出來，但是鎖由過期了，常見的思路是，鎖過期時間值遞增，但是想想不靠譜，因為第一個請求可能超時，如果后面的也超時呢，接連多次超時之后，鎖過期時間值勢必特別大了，這樣做弊端太多。

另外一個思路是，再開啟一個線程，進行監(jiān)控，如果取數(shù)據(jù)的線程沒有掛的話，就適當延遲鎖的過期時間。

4、穿透

穿透主要原因是很多請求都在訪問數(shù)據(jù)庫不存在的數(shù)據(jù)，例如一個賣書的商城一直被請求查詢茶葉產(chǎn)品，由于Redis緩存主要是用來緩存熱點數(shù)據(jù)，對于數(shù)據(jù)庫都不存在的數(shù)據(jù),是沒法緩存的，這種異常流量就會直接到達數(shù)據(jù)庫并且返回"沒有"的查詢結果。

應對這種請求，處理辦法是對訪問請求加一層過濾器，例如布隆過濾器、增強版布隆過濾器、布谷鳥過濾器。

除了布隆過濾器，可以增加一些參數(shù)檢驗，例如數(shù)據(jù)庫數(shù)據(jù)id一般都是遞增的，如果請求 id = -10 這種參數(shù)，勢必繞過Redis，避免這種情況，可以對用戶真實性檢驗等操作。

5、雪崩

雪崩，和擊穿類似，不同的是擊穿是一個熱點Key某時刻失效，而雪崩是大量的熱點Key在一瞬間失效，網(wǎng)絡上很多博客都在強調解決雪崩的策略是隨機過期時間，這個非常不準確，舉個例子，銀行做活動，之前這個利息系數(shù)為2%，過了零點系數(shù)改為3%，這種情況能將用戶的對應的key改為隨機過期嗎？如果用的過去的數(shù)據(jù)叫臟數(shù)據(jù)。

明顯不可以，同樣存錢f0c;你存到年底利息300萬，隔壁才200萬，這不得打架啊，開玩笑~

正確的思路是，首先要看看這個Key過期是不是時點性有關，時點性無關的話，可以隨機過期時間解決。

如果是時點性有關，例如剛剛說的銀行某一天改變某系數(shù)，那么就要利用強依賴擊穿方案，策略是先過去的線程更新一下所有key。