# 擊穿 大家都知道,計算機的瓶頸之一就是IO,為了解決記憶體與磁碟速度不匹配的問題,產生了快取,將一些熱點資料放在記憶體中,隨用隨取,降低連線到資料庫的請求連結,避免資料庫掛掉。需要注意的是,**無論是擊穿還是後面談到的穿透與雪崩,都是在高併發前提下**,當快取中某一個熱點key失效,  ## 為什麼會有擊穿發生呢? 有兩個主要原因: **Key過期** **Key被頁面置換淘汰** 對於第一個原因是因為在Redis中,Key有過期時間,如果某一個時刻(假如商城做活動,零點開始)key失效,那麼零點之後對某一個商品查詢請求將全都壓到資料庫上,導致資料庫崩。 對於第二個原因,因為記憶體是有限的,要時時刻刻快取新的資料,淘汰舊的資料,所以在一定的頁面置換策略([常見頁面置換演算法圖解](https://www.cnblogs.com/Courage129/p/14308698.html))中,淘汰資料,如果某些商品做活動之前無人問津,勢必會被淘汰。 ## 應對擊穿的處理思路 正常的處理請求如圖:  由於key過期在所難免,高流量來到Redis時,根據Redis的單執行緒特性,可以認為任務是在佇列裡依次執行的,當請求到達Redis發現Key過期時,進行一個操作:**設定鎖** 這個流程大概如下: 1. 請求到達Redis,發現Redis Key過期,檢視有沒有鎖,沒有鎖的話回到佇列後面排隊 2. 設定鎖,注意,這兒應該是setnx(),而不是set(),因為可能有其他執行緒已經設定鎖了 3. 獲取鎖,拿到鎖了就去資料庫取資料,請求返回後釋放鎖。  但是引出了一個新的問題,如果拿到鎖去拿資料的請求然後掛了怎麼辦?也就是鎖沒有釋放,其他程序都在等鎖,解決辦法是: 對鎖設定一個過期時間,如果到達了過期時間還沒釋放就自動釋放,問題又來了,鎖掛了好說,但是如果是鎖超時呢?也就是在設定的時間裡資料沒有取出來,但是鎖由過期了,常見的思路是,鎖過期時間值遞增,但是想想不靠譜,因為第一個請求可能超時,如果後面的也超時呢,接連多次超時之後,鎖過期時間值勢必特別大了,這樣做弊端太多。 另外一個思路是,再開啟一個執行緒,進行監控,如果取資料的執行緒沒有掛的話,就適當延遲鎖的過期時間。  # 穿透 穿透主要原因是很多請求都在訪問資料庫不存在的資料,例如一個賣書的商城一直被請求查詢茶葉產品,由於Redis快取主要是用來快取熱點資料,對於資料庫都不存在的資料,是沒法快取的,這種異常流量就會直接到達資料庫並且返回"沒有"的查詢結果。 應對這種請求,處理辦法是對訪問請求加一層過濾器,例如布隆過濾器、增強版布隆過濾器、布穀鳥過濾器,詳情見:[Redis布隆過濾器與布穀鳥過濾器](https://www.cnblogs.com/Courage129/p/14337466.html)  除了布隆過濾器,可以增加一些引數檢驗,例如資料庫資料id一般都是遞增的,如果請求 id = -10 這種引數,勢必繞過Redis,避免這種情況,可以對使用者真實性檢驗等操作。 # 雪崩 雪崩,和擊穿類似,不同的是擊穿是一個熱點Key某時刻失效,而雪崩是大量的熱點Key在一瞬間失效,網路上很多部落格都在強調解決雪崩的策略是隨機過期時間,這個非常不準確,舉個例子,銀行做活動,之前這個利息係數為2%,過了零點係數改為3%,這種情況能將使用者的對應的key改為隨機過期嗎?如果用的過去的資料叫髒資料。 明顯不可以,同樣存錢,你存到年底利息300萬,隔壁才200萬,這不得打架啊,開玩笑~ 正確的思路是,首先要看看這個Key過期是不是時點性有關,時點性無關的話,可以隨機過期時間解決。 如果是時點性有關,例如剛剛說的銀行某一天改變某係數,那麼就要利用強依賴擊穿方案,策略是先過去的執行緒更新一下所有key  在後臺更新熱點key的同時,業務層將進來的請求延時一下,例如短暫的睡幾毫秒或者秒,給後面的更新熱點key分散