Redis 大部分的使用場景，都是根據 key ，先在 Redis 中查詢，如果查詢不到的話，再查詢資料庫。

當有大量的請求，key 值根本不在 Redis 中，那麼查詢就會落到資料庫上，這些請求就彷彿“穿透”過了 Redis 落在了資料庫上，最後會導致資料庫不堪重負直至崩潰。

讓我們看看快取穿透的應對策略：

01. 將無效 key 儲存到 Redis 中

如果 Redis 中查詢不到，並且查詢資料庫也沒有結果，那麼就將這個 key 寫入到 Redis 中，設定 value = 空，這樣如果這個 key 值被重複訪問，也不會查詢資料庫。

但是如果資料庫幾分鐘後，存入了一條真實的資料，那麼就會發生資料庫和快取資料不一致的情況；

這種情況，要麼主動更新 Redis 中這條 key-空 的資料，要麼在設定快取的時候，同時設定快取的額過期時間，這樣當時間一過，快取資料就可以刷入到 Redis 中了。

如果每次查詢的 key 值都不相同，比如收到惡意攻擊，每次訪問都是無效且不相同的 key 值，那麼這個辦法就會失效。

02. 布隆過濾器

布隆過濾器（Bloom Filter）的原理解釋起來很複雜，用白話概括一下它的特點：它說某個 key 不存在，那麼就一定不存在，它說某個 key 存在，那麼很大可能是存在（存在一定的誤判率）。

使用布隆過濾器，擋回無效請求，流程大概是這樣的：

對布隆過濾器感興趣的同學，可以試一試 Google 出品的 Guava 工具庫，其中就有開箱即用的布隆過濾器：BloomFilter；

另外，Redis 在 4.0 之後有了外掛功能（Module），可以使用外部的擴充套件功能，可以使用 RedisBloom 作為 Redis 布隆過濾器外掛。

如何解決Redis快取穿透的問題？快取穿透是指查詢一個根本不存在的資料，快取層和儲存層都不會命中，通常出於容錯的考慮，如果從儲存層查不到資料則不寫入快取層，如圖所示整個過程分為如下3步：1）快取層不命中。2）儲存層不命中，不將空結果寫回快取。3）返回空結果。快取穿透將導致不存在的資料每次請求都要到儲存層去查詢，失去了快取保護後端儲存的意義。快取穿透問題可能會使後端儲存負載加大，由於很多後端儲存不具備高併發性，甚至可能造成後端儲存宕掉。通常可以在程式中分別統計總呼叫數、快取層命中數、儲存層命中數，如果發現大量儲存層空命中，可能就是出現了快取穿透問題。造成快取穿透的基本原因有兩個：第一，自身業務程式碼或者資料出現問題；第二，一些惡意攻擊、爬蟲等造成大量空命中。下面我們來看一下如何解決快取穿透問題。1.快取空物件如下圖所示，當第2步儲存層不命中後，仍然將空物件保留到快取層中，之後再訪問這個資料將會從快取中獲取，這樣就保護了後端資料來源。快取空物件會有兩個問題：第一，空值做了快取，意味著快取層中存了更多的鍵，需要更多的記憶體空間（如果是攻擊，問題更嚴重），比較有效的方法是針對這類資料設定一個較短的過期時間，讓其自動剔除。第二，快取層和儲存層的資料會有一段時間視窗的不一致，可能會對業務有一定影響。例如過期時間設定為5分鐘，如果此時儲存層添加了這個資料，那此段時間就會出現快取層和儲存層資料的不一致，此時可以利用訊息系統或者其他方式清除掉快取層中的空物件。

2.布隆過濾器攔截

如下所示，在訪問快取層和儲存層之前，將存在的key用布隆過濾器提前儲存起來，做第一層攔截。例如：一個推薦系統有4億個使用者id，每個小時演算法工程師會根據每個使用者之前歷史行為計算出推薦資料放到儲存層中，但是最新的使用者由於沒有歷史行為，就會發生快取穿透的行為，為此可以將所有推薦資料的使用者做成布隆過濾器。如果布隆過濾器認為該使用者id不存在，那麼就不會訪問儲存層，在一定程度保護了儲存層。

我們通常使用Redis快取+過期時間來加速網站的請求速度，減少後端資料庫的訪問壓力。同時也可以保證快取資料的及時更新。但是使用過程當中，就會產生快取穿透等相關快取問題。

快取穿透是指當用戶傳送的HTTP請求訪問到快取系統時，按照請求的KEY去查詢VALUE，當KEY對應的VALUE在快取系統裡面找不到的的時候，那麼這些大量的使用者請求就會訪問資料庫裡面。就會造成後端很大的壓力請求。

比如：快取就類似於後面訪問的防護牆，而防火牆在構建的時候可能會存在一些漏洞，就像古代城牆有時候都會有一些洞。而快取穿透就是透過這些漏洞讓大量的使用者請求訪問到我們這個資料庫，導致我們資料庫的壓力急劇上升。總結：請求沒有命中到快取資料，從而失去快取的意義直接去查詢資料庫了。但資料庫抗不住太多的請求，而導致系統崩潰快取使用原理

1、先從快取中取資料，如果能取到，直接返回資料給使用者。這樣就不用放入請求到資料庫，從而減輕資料庫的壓力。

2、如果快取中沒有資料，才會訪問資料庫。

快取穿透的造成原因

快取穿透的問題，一般在普通業務下請求量少是不存在的。肯定是再大併發情況下。因為你請求過多了，訪問的key的型別也多，但是快取系統，並不能夠完全包含所以key的訪問型別。依此為前提，原因如下：

1、惡意攻擊，猜測你的key命名方式，然後估計使用一個你快取中不會有的key進行訪問。

2、第一次資料訪問，這時快取中還沒有資料，則併發場景下，所有的請求都會壓到資料庫。

3、資料庫的資料也是空，這樣即使訪問了資料庫，也是獲取不到資料，那麼快取中肯定也沒有對應的資料。這樣也會導致穿透。

解決方案

1、在web伺服器啟動時，提前將有可能被頻繁併發訪問的資料提前寫入快取。規避大量的請求訪問到資料庫。

2、規範key的命名，並且統一快取查詢和寫入的入口。這樣，在入口處，對key的規範進行檢測。保證惡意的key被攔截。

3、快取層快取null並設定過期時間，為了避免記憶體耗盡，在後臺設定主動刪除空值，並把真實的快取值存進去。 不管資料庫中是否有資料，都在快取中儲存對應的key，null值即可。這樣是為了避免資料庫中沒有這個資料，導致的頻繁穿透快取對資料庫進行訪問。

4、採用布隆過濾器，可以先判斷key值是否存在，如果不存在，則不訪問redis，那這樣就可以攔截大量的請求，布隆過濾器恰好就是這樣設計的。