1.緩存穿透

1.1 問題描述

緩存穿透是在客戶端/瀏覽器端請求一個不存在的key，這個key在redis中不存在，在數(shù)據(jù)庫中也不存在數(shù)據(jù)源，每次對此key的請求從緩存獲取不到，就會請求數(shù)據(jù)源。

如使用一個不存在的用戶id去訪問用戶信息，redis和數(shù)據(jù)庫中都沒有，多次進行請求可能會壓垮數(shù)據(jù)源

1.2 解決方法

一個一定不存在緩存及查詢不到的數(shù)據(jù)，由于緩存是不命中時被動寫入的，緩存不存在，出于容錯考慮，查詢不到的數(shù)據(jù)是不會緩存在redis當中，這將導致每次請求不存在的數(shù)據(jù)都會請求數(shù)據(jù)庫，失去了緩存的意義。

（1）如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)是否不存在），我們?nèi)匀话堰@個空結(jié)果（null）進行緩存，設置空結(jié)果的過期時間會很短，最長不超過五分鐘

（2）設置可訪問的名單（白名單）：使用bitmaps類型定義一個可以訪問的名單，名單id作為bitmaps的偏移量，每次訪問和bitmap里面的id進行比較，如果訪問id不在bitmaps里面，進行攔截，不允許訪問。

（3）采用布隆過濾器

（4）進行實時的數(shù)據(jù)監(jiān)控，發(fā)現(xiàn)Redis在命中率急速降低時，排查訪問對象和訪問數(shù)據(jù)，設置黑名單。

2.緩存擊穿

2.1 問題描述

當用戶請求一個存在的key的數(shù)據(jù)時，此時redis中該key的數(shù)據(jù)已經(jīng)過時，此時若有大量并發(fā)請求發(fā)現(xiàn)緩存過期都會請求數(shù)據(jù)源加載數(shù)據(jù)并且緩存到redis當中，這個時候大量的并發(fā)可能會把數(shù)據(jù)庫服務壓垮。

2.2 解決方法

key可能在某一個時間段被大量的請求，這個key的數(shù)據(jù)被稱為熱點數(shù)據(jù)，這個時候便要考慮“擊穿”問題。

（1）預先設置熱門數(shù)據(jù)：在redis高峰訪問之前，把一些熱門數(shù)據(jù)提前存入到redis里面，加大這些熱門數(shù)據(jù)key的時長

（2）實時調(diào)整：現(xiàn)場監(jiān)控哪些數(shù)據(jù)熱門，實時調(diào)整key的過期時長

（3）使用鎖：

• 就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db。
• 先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX）去set一個mutex key
• 當操作返回成功時，再進行l(wèi)oad db的操作，并回設緩存,最后刪除mutex key；
• 當操作返回失敗，證明有線程在load db，當前線程睡眠一段時間再重試整個get緩存的方法。

3.緩存雪崩

3.1 問題描述

可以對應的數(shù)據(jù)存在，但是key的數(shù)據(jù)已經(jīng)過期（redis緩存過期，會自動刪除此key），此時大量的并發(fā)請求訪問不同的key，即同時大量的訪問不同的key，此時key處于過期階段，便會請求數(shù)據(jù)庫，大量的并發(fā)請求會壓垮數(shù)據(jù)庫服務器，這種情況被稱為緩存雪崩，和緩存擊穿的不同是前者是一個key。

3.2 解決方法

緩存失效時的雪崩效應對底層系統(tǒng)的沖擊非常可怕！

（1） 構(gòu)建多級緩存架構(gòu)：

• nginx緩存 + redis緩存 +其他緩存（ehcache等）

（2） 使用鎖或隊列：

• 用加鎖或者隊列的方式保證來保證不會有大量的線程對數(shù)據(jù)庫一次性進行讀寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。不適用高并發(fā)情況

（3） 設置過期標志更新緩存：

• 記錄緩存數(shù)據(jù)是否過期（設置提前量），如果過期會觸發(fā)通知另外的線程在后臺去更新實際key的緩存。

（4） 將緩存失效時間分散開：

• 比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重復率就會降低，就很難引發(fā)集體失效的事件。