一、Redis穿透

緩存穿透現象：用戶想要查詢一個數據，發現redis內存數據庫沒有，也就是緩存沒有命中，于是向持久層數據庫查詢。發現也沒有，于是本次查詢失敗。當用戶很多的時候，緩存都沒有命中，于是都去請求了持久層數據庫。這會給持久層數據庫造成很大的壓力，這時候就相當于出現了緩存穿透。

介紹兩種常用解決方案：

1.解決方案1：布隆過濾器

參考下面這篇文章，我覺得講得非常詳細了，

詳解布隆過濾器的原理、使用場景和注意事項

2.解決方案2：緩存空對象

緩存穿透：黑客發送大量請求，請求的數據是數據庫里沒有的，每次都會不走緩存，直接走數據庫，最后可能造成數據庫宕機

解決：只要數據庫沒查到，就寫一個空值到緩存，下次還有這個請求，就可以走緩存了

弊端：

如果空值能夠被緩存起來，這就意味著緩存需要更多的空間存儲更多的鍵，因為這當中可能會有很多的空值的鍵；

即使對空值設置了過期時間，還是會存在緩存層和存儲層的數據會有一段時間窗口的不一致，這對于需要保持一致性的業務會有影響。

二、Redis擊穿

XXX

三、Redis雪崩

緩存雪崩現象：大量key同一時間點全部失效，同時又有大量請求打進來，導致流量直接打在DB上，造成DB不可用。

那么思考下以下幾個問題：

• Redis緩存為什么會大量key同一時間點全部失敗？
• 數據庫能支持的最大并發請求數是多少？
• 數據庫掛掉了DBA會怎么處理？

要想了解上面的問題，看下下面這張圖：

1.Redis為什么會出現大量key同一時間點全部失效？

Redis服務器宕機了，Redis服務器宕機一般是因為并發數超過Redis服務器能支撐的最大的并發數。具體案例可以看下記一次redis掛機導致的服務雪崩事故，不對，是故事~ （非常好的雪崩案例分析）

2.再來看下數據庫能支撐的最大并發請求數？

數據庫類型支持的最大并發數備注

MySql	16384	受服務器配置，及網絡環境等制約，實際服務器支持的并發連接數會小一些，主要決定因素有： 1、服務器CPU及內存的配置。 2、網絡的帶寬。互聯網連接中上行帶寬的影響尤為明顯。
Oracle	40000	1.查看oracle的最大并發數限制，可是查看v$license視圖 2.手動計算：每個Session消耗的內存和參數設置有關，如果是DEDICATE（獨立模式）方式，sort_area_size大小和PGA內存消耗相關，如果是512K，則大概每個Session消耗3M左右，所以，機器允許的最大并發連接數＝（機器內存－ORACLE等系統軟件內存－oracleSGa內存）/3m
? Postgre	大于Oracle	1.最大連接數也可以在pg配置文件中配置： 在postgresql.conf中設置： max_connections = 500 2.查看為超級用戶保留的連接數： show superuser_reserved_connections ;?

3.Redis雪崩的解決方案

（1）redis高可用

這個思想的含義是，既然redis有可能掛掉，那我多增設幾臺redis，這樣一臺掛掉之后其他的還可以繼續工作，其實就是搭建的集群。

（2）限流降級

這個解決方案的思想是，在緩存失效后，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。

（3）數據預熱

數據加熱的含義就是在正式部署之前，我先把可能的數據先預先訪問一遍，這樣部分可能大量訪問的數據就會加載到緩存中。在即將發生大并發訪問前手動觸發加載緩存不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻。

具體案例可以看下上圖案例的解決方案

參考文章：

幫你解讀什么是Redis緩存穿透和緩存雪崩（包含解決方案）

詳解布隆過濾器的原理、使用場景和注意事項

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的Redis系列（二）：Redis缓存穿透和缓存雪崩是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。