快取穿透快取擊穿快取雪崩

二、快取擊穿

三、快取雪崩

快取穿透：快取和資料庫中都沒有的資料，可使用者還是源源不斷的發起請求，導致每次請求都會到資料庫，從而壓垮資料庫。

如下圖紅色的流程：

比如客戶查詢乙個根本不存在的東西，首先從redis中查不到，然後會去資料庫中查詢，資料庫中也查詢不到，那麼就不會將資料放入到快取中，後面如果還有類似源源不斷的請求，最後都會壓到資料庫來處理，從而給資料庫造成巨大的壓力。

①、業務層校驗

使用者發過來的請求，根據請求引數進行校驗，對於明顯錯誤的引數，直接攔截返回。

比如，請求引數為主鍵自增id，那麼對於請求小於0的id引數，明顯不符合，可以直接返回錯誤請求。

②、不存在資料設定短過期時間

對於某個查詢為空的資料，可以將這個空結果進行redis快取，但是設定很短的過期時間，比如30s，可以根據實際業務設定。注意一定不要影響正常業務。

③、布隆過濾器

關於布隆過濾器，後面會詳細介紹。布隆過濾器是一種資料結構，利用極小的記憶體，可以判斷大量的資料「一定不存在或者可能存在」。

對於快取穿透，我們可以將查詢的資料條件都雜湊到乙個足夠大的布隆過濾器中，使用者傳送的請求會先被布隆過濾器攔截，一定不存在的資料就直接攔截返回了，從而避免下一步對資料庫的壓力。

快取擊穿：redis中乙個熱點key在失效的同時，大量的請求過來，從而會全部到達資料庫，壓垮資料庫。

這裡要注意的是這是某乙個熱點key過期失效，和後面介紹快取雪崩是有區別的。比如**雙十一，對於某個**熱門的商品資訊，快取在redis中，剛好0點，這個商品資訊在redis中過期查不到了，這時候大量的使用者又同時正好訪問這個商品，就會造成大量的請求同時到達資料庫。

①、設定熱點資料永不過期

對於某個需要頻繁獲取的資訊，快取在redis中，並設定其永不過期。當然這種方式比較粗暴，對於某些業務場景是不適合的。

②、定時更新

比如這個熱點資料的過期時間是1h，那麼每到59minutes時，通過定時任務去更新這個熱點key，並重新設定其過期時間。

③、互斥鎖

這是解決快取擊穿比較常用的方法。

互斥鎖簡單來說就是在redis中根據key獲得的value值為空時，先鎖上，然後從資料庫載入，載入完畢，釋放鎖。若其他執行緒也在請求該key時，發現獲取鎖失敗，則睡眠一段時間（比如100ms）後重試。

快取雪崩：redis中快取的資料大面積同時失效，或者redis宕機，從而會導致大量請求直接到資料庫，壓垮資料庫。

對於乙個業務系統，如果redis宕機或大面積的key同時過期，會導致大量請求同時打到資料庫，這是災難性的問題。

①、設定有效期均勻分布

避免快取設定相近的有效期，我們可以在設定有效期時增加隨機值；

或者統一規劃有效期，使得過期時間均勻分布。

②、資料預熱

對於即將來臨的大量請求，我們可以提前走一遍系統，將資料提前快取在redis中，並設定不同的過期時間。

③、保證redis服務高可用

前面我們介紹過redis的哨兵模式和集群模式，為防止redis集群單節點故障，可以通過這兩種模式實現高可用。

快取穿透 快取擊穿 快取雪崩