基於Redis緩存數據常見的三種問題及解決
1.緩存穿透
1.1 問題描述
緩存穿透是在客戶端/瀏覽器端請求一個不存在的key，這個key在redis中不存在，在數據庫中也不存在數據源，每次對此key的請求從緩存獲取不到，就會請求數據源。
如使用一個不存在的用戶id去訪問用戶信息，redis和數據庫中都沒有，多次進行請求可能會壓垮數據源
1.2 解決方法
一個一定不存在緩存及查詢不到的數據，由於緩存是不命中時被動寫入的，緩存不存在，出於容錯考慮，查詢不到的數據是不會緩存在redis當中，這將導致每次請求不存在的數據都會請求數據庫，失去瞭緩存的意義。
（1）如果一個查詢返回的數據為空（不管是數據是否不存在），我們仍然把這個空結果（null）進行緩存，設置空結果的過期時間會很短，最長不超過五分鐘
（2）設置可訪問的名單（白名單）：使用bitmaps類型定義一個可以訪問的名單，名單id作為bitmaps的偏移量，每次訪問和bitmap裡面的id進行比較，如果訪問id不在bitmaps裡面，進行攔截，不允許訪問。
（3）采用佈隆過濾器
（4）進行實時的數據監控，發現Redis在命中率急速降低時，排查訪問對象和訪問數據，設置黑名單。
2.緩存擊穿
2.1 問題描述
當用戶請求一個存在的key的數據時，此時redis中該key的數據已經過時，此時若有大量並發請求發現緩存過期都會請求數據源加載數據並且緩存到redis當中，這個時候大量的並發可能會把數據庫服務壓垮。
2.2 解決方法
key可能在某一個時間段被大量的請求，這個key的數據被稱為熱點數據，這個時候便要考慮“擊穿”問題。
（1）預先設置熱門數據：在redis高峰訪問之前，把一些熱門數據提前存入到redis裡面，加大這些熱門數據key的時長
（2）實時調整：現場監控哪些數據熱門，實時調整key的過期時長
（3）使用鎖：
- 就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db。
- 先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX）去set一個mutex key
- 當操作返回成功時，再進行load db的操作，並回設緩存,最後刪除mutex key；
- 當操作返回失敗，證明有線程在load db，當前線程睡眠一段時間再重試整個get緩存的方法。
3.緩存雪崩
3.1 問題描述
可以對應的數據存在，但是key的數據已經過期（redis緩存過期，會自動刪除此key），此時大量的並發請求訪問不同的key，即同時大量的訪問不同的key，此時key處於過期階段，便會請求數據庫，大量的並發請求會壓垮數據庫服務器，這種情況被稱為緩存雪崩，和緩存擊穿的不同是前者是一個key。
3.2 解決方法
緩存失效時的雪崩效應對底層系統的沖擊非常可怕！
（1） 構建多級緩存架構：
- nginx緩存 + redis緩存 +其他緩存（ehcache等）
（2） 使用鎖或隊列：
- 用加鎖或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，從而避免失效時大量的並發請求落到底層存儲系統上。不適用高並發情況
（3） 設置過期標志更新緩存：
- 記錄緩存數據是否過期（設置提前量），如果過期會觸發通知另外的線程在後臺去更新實際key的緩存。
（4） 將緩存失效時間分散開：
- 比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重復率就會降低，就很難引發集體失效的事件。
以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。