站長資訊網本篇文章給大家帶來了關于Redis的相關知識，主要介紹三種緩存問題，也就是緩存穿透、緩存擊穿和緩存雪崩的相關內容，希望對大家有幫助。
推薦學習：Redis學習教程
一、Redis緩存的應用
在我們的實際業務場景中，Redis 一般和其他數據庫搭配使用，用來減輕后端數據庫的壓力，比如和關系型數據庫 MySQL 配合使用。
Redis 會把 MySQL 中經常被查詢的數據緩存起來，比如熱點數據，這樣當用戶來訪問的時候，就不需要到 MySQL 中去查詢了，而是直接獲取 Redis 中的緩存數據，從而降低了后端數據庫的讀取壓力。
如果說用戶查詢的數據 Redis 沒有，此時用戶的查詢請求就會轉到 MySQL 數據庫，當 MySQL 將數據返回給客戶端時，同時會將數據緩存到 Redis 中，這樣用戶再次讀取時，就可以直接從 Redis 中獲取數據。流程圖如下所示：
當然，我們在使用Redis作為緩存數據庫的過程中也并不是總能一帆風順，我們會遇到常見的三種緩存問題：
- 緩存穿透
- 緩存擊穿
- 緩存雪崩
二、緩存穿透
2.1 介紹
緩存穿透是指當用戶查詢某個數據時，Redis 中不存在該數據，也就是緩存沒有命中，此時查詢請求就會轉向持久層數據庫 MySQL，結果發現 MySQL 中也不存在該數據，MySQL 只能返回一個空對象，代表此次查詢失敗。如果這種類請求非常多，或者用戶利用這種請求進行惡意攻擊，就會給 MySQL 數據庫造成很大壓力，甚至于崩潰，這種現象就叫緩存穿透。
2.2 解決方案
緩存空對象
當 MySQL 返回空對象時， Redis 將該對象緩存起來，同時為其設置一個過期時間。當用戶再次發起相同請求時，就會從緩存中拿到一個空對象，用戶的請求被阻斷在了緩存層，從而保護了后端數據庫，但是這種做法也存在一些問題，雖然請求進不了 MSQL，但是這種策略會占用 Redis 的緩存空間。
布隆過濾器
首先將用戶可能會訪問的熱點數據的所有key存儲在布隆過濾器中（也稱緩存預熱），當有一個用戶請求時會先經過布隆過濾器，布隆過濾器會判斷請求的key是否存在，若不存在，那么該請求將直接被拒絕，否則將繼續執行查詢，先前往緩存中查詢，緩存沒有的話再前往數據庫中查詢。相較于第一種方法，用布隆過濾器方法更為高效、實用。其流程示意圖如下：
緩存預熱：是指系統啟動時，提前將相關的數據加載到 Redis 緩存系統中。這樣避免了用戶請求的時再去加載數據。
2.3 解決方案的比較
兩種方案都可以解決緩存穿透的問題，但其使用的場景卻不同：
緩存空對象：適用于空數據的key數量有限、key重復請求概率較高的場景。
布隆過濾器：適用于空數據的key各不相同、key重復請求概率較低的場景。
三、緩存擊穿
3.1 介紹
緩存擊穿是指用戶查詢的數據緩存中不存在，但是后端數據庫卻存在，這種現象出現原因是一般是由緩存中 key 過期導致的。比如一個熱點數據 key，它無時無刻都在接受大量的并發訪問，如果某一時刻這個 key 突然失效了，就致使大量的并發請求進入后端數據庫，導致其壓力瞬間增大。這種現象被稱為緩存擊穿。
3.2 解決方案
改變過期時間
設置熱點數據永不過期。
分布式鎖
采用分布式鎖的方法，重新設計緩存的使用方式，過程如下：
- 上鎖：當我們通過 key 去查詢數據時，首先查詢緩存，如果沒有，就通過分布式鎖進行加鎖，第一個獲取鎖的進程進入后端數據庫查詢，并將查詢結果緩到Redis 中。
- 解鎖：當其他進程發現鎖被某個進程占用時，就進入等待狀態，直至解鎖后，其余進程再依次訪問被緩存的 key。
3.3 解決方案的比較
永遠不過期 ：這種方案由于沒有設置真正的過期時間，實際上已經不存在熱點 key 產生的一系列危害，但是會存在數據不一致的情況，同時代碼復雜度會增大。
互斥鎖：這種方案思路比較簡單，但是存在一定的隱患，如果構建緩存過程出現問題或者時間較長，可能會存在死鎖和線程池阻塞的風險，但是這種方法能夠較好的降低后端存儲負載并在一致性上做的比較好。
四、緩存雪崩
4.1 介紹
緩存雪崩是指緩存中大批量的 key 同時過期，而此時數據訪問量又非常大，從而導致后端數據庫壓力突然暴增，甚至會掛掉，這種現象被稱為緩存雪崩。它和緩存擊穿不同，緩存擊穿是在并發量特別大時，某一個熱點 key 突然過期，而緩存雪崩則是大量的 key 同時過期，因此它們根本不是一個量級。
4.2 解決方案
處理過期
緩存雪崩和緩存擊穿有相似之處，所以也可以采用熱點數據永不過期的方法，來減少大批量的 key 同時過期。再者就是為 key 設置隨機過期時間，避免 key 集中過期。
redis高可用
一臺Redis可能會因為雪崩而掛掉，那么可以多增設幾臺Redis，搭建集群，如果一臺掛掉之后，其他的還可以繼續工作。
推薦學習：Redis學習教程
