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