有沒有人告訴過你，更復(fù)雜的緩存穿透怎么解決？

你應(yīng)該從網(wǎng)上看過太多的文章說緩存穿透怎么解決？無非就是布隆過濾器，緩存空值什么的。

但是，更深入的一個問題，緩存空值有沒有問題？如果緩存的空值太多怎么辦？

如果用的redis，那么太多的空值會不會打爆你的redis？如果用的本地緩存，會不會打爆你的內(nèi)存？繼而引發(fā)的問題就是還是會打爆你的數(shù)據(jù)庫。

從線上問題說起

前不久，我們線上環(huán)境壓測，在QPS壓倒2W之后RT達到了幾十秒，排查后發(fā)現(xiàn)是redis的連接數(shù)不夠?qū)е麓罅康倪B接超時。

經(jīng)過考慮之后，我們最終決定棄用redis緩存的方案，改為本地緩存，因為我們緩存的都是一些配置信息，實際上幾個月都不太可能修改，而redis配置的連接數(shù)是200，5分鐘超時，數(shù)據(jù)量實際上也就只有幾千條而已，實際上來說并沒有很大的必要，本地緩存完全就可以解決問題了。

本地緩存使用Guava的LoadingCache實現(xiàn)。

但是修改完之后，壓測之后還是發(fā)現(xiàn)有接口全部走到數(shù)據(jù)庫查詢，先排查代碼，是否是代碼的BUG導(dǎo)致實際沒有生效，后來發(fā)現(xiàn)實際上發(fā)生了緩存穿透，壓測使用了一些數(shù)據(jù)庫中不存在的記錄，導(dǎo)致了穿透的問題，實際上這個問題在使用redis的時候也一直存在，只是由于連接數(shù)的問題一直沒有發(fā)現(xiàn)而已。

接下來就是考慮怎么解決的問題？

由于我們都是緩存的一些配置信息，幾千條數(shù)據(jù)而已，最終考慮簡單解決的辦法。直接把所有的key全部從數(shù)據(jù)庫查出來緩存下來，查數(shù)據(jù)庫之前直接根據(jù)key過濾一把，如果不存在就直接返回，不要走數(shù)據(jù)庫查詢了。

當然，這是由于我們的場景比較簡單，這樣直接處理就行了，那么，如果再復(fù)雜一點，比如上億的緩存數(shù)據(jù)呢？

解決方案

前置過濾

如果說類似我這種比較簡單的一些緩存，使用我上面說的解決方案也可以，還有一些緩存的key是比如ID之類，也可以根據(jù)一定的范圍規(guī)則去提前過濾，比如緩存的key明確知道在1-10萬的范圍之后，那么過濾掉在這個范圍之外的請求直接返回就可以了。

當然，很明顯這種簡單的規(guī)則過濾適用于數(shù)據(jù)量不是很大，并且數(shù)據(jù)不會頻繁發(fā)生改變的情況。

布隆過濾器

對于上述場景，因為數(shù)據(jù)量很小，簡單的代碼實現(xiàn)緩存即可，如果說數(shù)據(jù)量很大的話，比如有一億個key，使用布隆過濾器就是個更優(yōu)解。

我們可以每天定時把所有的配置信息從數(shù)據(jù)庫中查詢出來構(gòu)建成bitmap。

關(guān)于布隆過濾器我前面的文章也有寫過，貼上之前的圖一張，如果查詢的位置都是1的話說明key存在，反之只要有一個0則說明肯定不存在。

使用布隆過濾器的缺點也很明顯，存在一定概率的誤判。當然，既然用了，對于誤判比例、內(nèi)存占用等等問題應(yīng)該事先評估好。

緩存空值

這個是網(wǎng)上說爛的問題，但是緩存空值的空值太多明顯也是有問題的，再進一步解決方案就是快速過期。

一般來說，普通的緩存的寫法如下，先查緩存，如果緩存存在則直接返回，如果緩存沒有則去數(shù)據(jù)庫查詢，結(jié)果不是空就保存到緩存中。

改進版的寫法就是緩存空對象，針對空的數(shù)據(jù)，設(shè)置過期時間，比如10分鐘，快速過期，防止太多的空值問題。

但是這個解決方案仍然有點小問題，就是短暫的數(shù)據(jù)不一致的問題。

想象一下如果緩存的空值這時候?qū)嶋H上已經(jīng)有值了，那么在過期時間的這段時間內(nèi)就可能存在短暫的數(shù)據(jù)不一致。

總結(jié)

緩存穿透的問題總結(jié)下來就是三點，這三個方式不是說是隔離的解決方案，他們可以結(jié)合在一起使用。

首先看數(shù)據(jù)量，如果數(shù)據(jù)量很小并且沒有頻繁變更的話，選擇前置過濾的方式，根據(jù)具體的業(yè)務(wù)規(guī)則來處理就可以。

如果數(shù)據(jù)量大的話，可以選擇使用布隆過濾器，但是存在一定概率的誤判。

通過前置的攔截，應(yīng)該攔截住大部分的流量，避免直接打爆數(shù)據(jù)庫。

最后，可以使用緩存空值并且設(shè)置快速過期的方式來作為一個兜底的方案。

如果還有問題，那么就是限流、降級了。