如何理解Redis雪崩、擊穿、穿透、預熱、降級

這篇文章主要講解了“如何理解Redis雪崩、擊穿、穿透、預熱、降級”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解Redis雪崩、擊穿、穿透、預熱、降級”吧！

緩存擊穿

緩存擊穿根據名字根本無法看懂是什么意思，并且很容易和另一個詞——緩存穿透搞混。緩存擊穿指的是某個 key 一直在扛著高并發，所謂扛著高并發就是說大量的請求都是獲取這個 key 對應的值。

而這個 key 在某個時間突然失效了，那是不是就意味著大量的請求就無法在緩存中獲取數據了，而是去請求數據庫了，這樣很有可能導致數據庫被擊垮。這就是緩存擊穿。

那現在問題知道了，該如何應對呢？這個就比較簡單了，既然這個 key 這個受歡迎，那么就不要設置過期時間了，如果該key的數據更新了，那么就通過互斥鎖的方式將其更新。

為什么要用互斥鎖的方式？如果不使用互斥鎖的方式很容易導致數據不一致的情況，這里為了保證緩存和數據庫的一致性，就只能犧牲一點點的效率了。

緩存雪崩

不知道各位小伙伴都是來自哪里，我們那邊有句方言叫“雪崩”，表示事情砸了的意思。這里的Redis 雪崩似乎有點異曲同工之妙。首先我們需要知道什么是 Redis雪崩，

Redis雪崩我們一般都稱為緩存雪崩，意思就是說在某個時間節點，大量的 key 失效，導致大量的請求從緩存中獲取不到數據而去請求數據庫。根據上面的那張圖，我們再來畫下雪崩的情況的是什么樣子的：

上面的黑色的部分表示緩存無效了，也就意味著所有的請求都需要到數據庫中去查詢數據。那這對于數據庫的壓力必然是劇增的，如果是在一線互聯網這樣超高并發的場景下，數據庫直接宕機。

重啟也沒有用，因為重啟了還會有巨大的流量涌進來，然后繼續被搞宕機。所以對于預防緩存雪崩這種情況的發生意義還是很大的的。

緩存雪崩解決方案之加隨機值

上面已經詳細介紹了什么是緩存雪崩，他是怎么發生的，那如果防止緩存雪崩呢？

很簡單，因為上面剛剛說到，緩存雪崩是由于某個時間節點大量的 key 失效而導致的問題，那現在的問題不就是變成了如何防止同一個時間節點大量的 key 失效這種情況發生嗎？

最簡單的情況就是把key的過期時間分散開，也就是在設置key的過期時間的時候再加一個隨機值，就這樣就能完美的解決緩存雪崩的問題。

但是你以為我說到這里就完事了？既然是一次全安排，那么我一定不會僅僅告訴你一種解決方案就完事的。繼續看

緩存雪崩解決方案之加鎖

可能很多人看到這個方案表示不接受，加鎖那不是限制了并發？加鎖必然導致阻塞。如果是加鎖，那么執行就成就是這個樣子了：

流程是這樣子的，在多個請求同時到達業務系統時候，只能有一個線程能獲取到鎖，然后才能繼續去緩存或者是數據庫中查詢數據，然后后面的流程和之前的是一樣的，執行完成后釋放鎖，然后其他線程再爭搶鎖，然后重復前面的流程。

這個方案的優點是可以很好的保護數據庫不會被打掛，缺點就是并發度極低。

上面這個方案其實還是可以再優化下的：

這個就是在緩存中如果獲取不到，再去串行的訪問數據看，這里不一定非要串行，可以配合線程池，控制一定的并發數。

這個缺點雖然很多，但是也是一種解決方案。用不用就看實際的業務場景了。畢竟沒有沒用技術方案，只有不適合業務場景的技術方案（手動狗頭）。

緩存穿透

緩存穿透意思就是某個不存在的key一直被訪問，結果發現數據庫中也沒有這樣的數據，最終導致訪問該key的所有請求都直接請求到數據庫了。如果是并發高的場景下就容易搞垮數據庫。大家有沒有發現我們做的一些事情都是在保護“弱小的數據庫”。

那現在問題已經知道了，我們該如何去解決這個問題呢？

緩存穿透解決方案之緩存空數據

啥叫緩存空數據？就是假設某個key數據并不存在，那么就存一個 NULL 就好了，但是一定不要忘記設置過期時間，因為假設id=3的記錄不存在，然后本次訪問沒有查詢到數據，緩存中存的是null如果過一會兒新增了一條記錄為3的數據，如果緩存不設置過期時間，那么這條數據就永遠獲取不到。

緩存穿透解決方案之布隆過濾器

布隆過濾器？這玩意到底什么意思？

布隆過濾器是一種數據結構，更準確的說是一種概率型的數據結構，因為它能判斷某個元素一定不存在或者是可能存在。

就這句話，搞蒙了很多人，今天我非要把你說明白了。布隆過濾器是一個bit數組，一個很長的bit數組和一系列的hash函數構成。先看下圖

我們現在來舉個例子，假設現在有小強和旺財兩個人，他們分別經過三次hash得到的下標是這樣子的（布隆過濾器不存儲元素，僅僅是為一個元素是否存在打一個標志）

小強經過上面的三個hash后得到的下標分別為：2、4、5，那么該數組的2、4、5位置就會被置為1，也就是此時是這樣子的

同樣旺財經過上面的三個hash后得到的下標分別為：3、7、11，那么該數組的3、7、11位置就會被置為1，也就是此時是這樣子的

現在假設來一個 007 經過上面的三個hash后得到的下標分別為：11、13、15因為13、和15位置是0，所以一定可以判斷007 一定不存在。但是現在又來了一個

9527經過上面的三個hash后得到的下標分別為：2、5、7，但是你會發現257三個位置全部是1，那這個到底說明9527是存在還是不存在呢？

從我們上面的講解可以 9527 之前并不存在，但是由于hash沖突，但是9527的三個下標值也剛好落在已經被置為1的下標位置，這就導致此時是無法判斷9527是否存在的。這就是布隆過濾器的原理。

要不來段代碼壓壓驚？

我們來使用 google 包下的類來測試。首先要添加依賴

<dependency>      <groupId>com.google.guava</groupId>      <artifactId>guava</artifactId>      <version>30.1-jre</version>  </dependency>

代碼如下（詳細的解釋我已經寫在注釋中了，這個是可以用于實際生產的代碼）

public class BloomFilterDemo {      public static void main(String[] args) {          /**           * 創建一個插入對象為一億，誤報率為0.01%的布隆過濾器           * 不存在一定不存在           * 存在不一定存在           */          BloomFilter<CharSequence> bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charset.forName("utf-8")),                  100000000,                  0.0001);          bloomFilter.put("死");          bloomFilter.put("磕");          bloomFilter.put("Redis");          System.out.println(bloomFilter.mightContain("Redis"));          System.out.println(bloomFilter.mightContain("死"));          System.out.println(bloomFilter.mightContain("磕"));          System.out.println(bloomFilter.mightContain("Java"));      }  }

結果

完。

等等……緩存穿透、預熱、降級你還沒說呢。哦，我真的以為本文結束了。

那布隆過濾器是如何解決緩存穿透的問題的呢？既然已經知道了布隆過濾器的原理，那么就可以通過布隆過濾器來快速的判斷出一個key是否存在數據庫中，如果可能存在再去數據庫查詢，如果布隆過濾器中不存在那么就需要再去數據庫查詢了。

緩存預熱

這又是什么鬼？怎么搞一個緩存還有這么多問題，那還要緩存干啥？

所謂緩存預熱就是將一些可能經常使用數據在系統啟動的時候預先設置到緩存中，這樣可以避免在使用到的時候先去數據庫中查詢。

這就是緩存預熱，名氣高大上，實際上很簡單有木有，這個緩存預熱我在實際場景是經常使用的。

還有一種方式就是添加一個緩存刷新頁，這樣通過人工干預的方式將一些可能為熱點的key添加到緩存中。

緩存降級

當訪問量突然劇增（例如下班的點，大家都在地鐵上刷手機呢）、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。

系統可以根據一些關鍵數據進行自動降級，降級的最終目的是保證核心服務可用，即使是有損的。但是有的一些業務的核心服務是不能降級的。這是一種丟卒保帥的思想。

感謝各位的閱讀，以上就是“如何理解Redis雪崩、擊穿、穿透、預熱、降級”的內容了，經過本文的學習后，相信大家對如何理解Redis雪崩、擊穿、穿透、預熱、降級這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！