【乾貨！！】三句話搞懂 Redis 緩存穿透、擊穿、雪崩

前言

如何有效的理解而且區分 Reids 穿透、擊穿和雪崩之間的區別，一直以來都挺困擾個人。特別是穿透和擊穿，過一段時間就稀裏糊塗的分不清了。

爲了有效的幫助筆者本身，以及擁有一樣煩惱的朋友們區分這三種場景。筆者總結了一些 關鍵詞，但願你們能夠和我同樣經過聯想的方式來區分並理解這三種場景的區別！

緩存穿透：

關鍵詞：穿過 Redis 和 數據庫

當 Redis 和數據庫中都沒有咱們想要的數據時，就須要考慮緩存穿透的問題了

下面這段邏輯你們用的會比較多：先去 Redis 中查找某資源，Redis 中查不到就去 DB 中查，DB 中查到後回寫一份數據到 Redis 中。

這段邏輯正常狀況下問題並不大，可是若是用戶惡意重複請求資源 X，該資源在 Redis 和 DB 中都不存在。那麼每次請求都會直接打到 DB 上，甚至致使物理 DB 宕機。

解決方案：

一、緩存空結果

若是系統發現 Redis 及 DB 中都不存在該資源，就緩存空結果一段時間。須要注意哈，此次的失效時間不能設置的太長，不然數據的實效性會產生很大的問題。

二、用戶合法性校驗

對用戶的請求合法性進行校驗，攔截惡意重複請求

三、布隆過濾器

看到這個名詞不要慌。簡單來講布隆過濾器的用途就是幫助你判斷某個值是否存在。

舉個例子來看下：
假設咱們如今有一個長度爲 9 的 bit 數組，該數組的每一個位置上只能保存 1 或者 0，1 標識該位置被佔用，0 標識該位置未被使用。

1. 對於 key1,咱們藉助三個 Hash 函數分別對其哈希運算
2. 再將獲得的這三個哈希值對 9 求模。
3. 最後將這三個模值落入到 bit 數組上。
4. key二、key3 按照一樣的方式再處理一遍。

key值 | 模值

key1 | 一、四、6
key2 | 二、五、7
key3 | 六、八、9

最後，咱們會發現這個 bit 數組裏只有位置 3 仍是空着的。若是此時來了一個新的 key4 經過三個Hash算法求出的哈希值爲 一、二、3，咱們則能夠判定 key4 必定不存在。

布隆過濾器的原理仍是比較簡單的。這裏咱們須要注意，布隆過濾器可能存在必定誤判的可能性，但它依然能夠幫助你攔截掉大部分必定不存在的數據。

緩存擊穿

關鍵詞：定點打擊

試想若是全部請求對着一個 key 照死裏搞，這是否是就是一種定點打擊呢？

怎麼理解呢？舉個極端的例子：好比某某明星爆出一個驚天狠料，海量吃瓜羣衆同時訪問微博去查看該八卦新聞，而微博 Redis 集羣中數據在此刻正好過時了，那麼無數的請求則直接打到了微博系統的物理 DB 上，DB 瞬間掛了。

解決方案：

一、熱點數據永遠不過時

好比咱們能夠將某個 key 的緩存時間設置爲 25 小時，而後後臺有個 JOB 每隔 24 小時就去批量刷新一下熱點數據。就能夠解決這個問題了

二、使用互斥鎖

容易影響吞吐量，大部分項目設置熱點 key 永不過時就妥妥的了

緩存雪崩

關鍵詞：Redis 崩了，沒有數據了

這裏的 Redis 崩了指的並非 Redis 集羣宕機了。而是說在某個時刻 Redis 集羣中的熱點 key 都失效了。

若是集羣中的熱點 key 在某一時刻同時失效了的話，試想海量的請求都將直接打到 DB 上，DB 可能在瞬間就被打爆了。

解決方案

一、Redis 失效時間加上隨機數

Redis 失效時間加上隨機數，是一種比較取巧的解決方案。在必定程度上減輕了 DB 的瞬時壓力，可是這種方案也在必定程度上增長了維護的成本。

二、Redis 永不過時

實現方案在上文中簡單提過了

總結

最後咱們再回歸到主題！

如何輕鬆的經過聯想的方式來區分 Redis 緩存穿透、擊穿、雪崩的區別

• 緩存穿透---穿過（繞過） Redis 和 DB 來搞你
• 緩存擊穿---定點打擊來搞你
• 緩存雪崩---熱點 key 在某一個時刻同時失效

---

若是你以爲文章寫的還不錯，快給筆者點個贊吧，你的鼓勵是筆者創做最大的支持！！！！！！