Redis緩存穿透出現(xiàn)原因及解決方案

在并發(fā)式的項目當(dāng)中，一定要考慮一個緩存穿透的情況。那么什么是緩存穿透呢？簡單的說來，就是當(dāng)大量請求的key根本不在緩存當(dāng)中，所以導(dǎo)致了請求直接到了數(shù)據(jù)庫上，根本沒有經(jīng)過緩存這一層。比如一個黑客故意制造我們緩存中不存在的key發(fā)送大量的請求，就會導(dǎo)致請求直接落到數(shù)據(jù)庫上。

也就是說，緩存穿透就是：1.緩存層不命中。2，存儲層不命中，不將空的結(jié)果寫回緩存。3，返回空結(jié)果給客戶端。

一般mysql的默認最大連接數(shù)是150左右，當(dāng)然這個是可以用show variables like ‘%max_connections%'命令來查看。

當(dāng)然這只是一個指標(biāo)，cpu磁盤內(nèi)存網(wǎng)絡(luò)等等原因都影響了他的并發(fā)能力，所以一般3000的并發(fā)請求就可以殺死大部分的數(shù)據(jù)庫。

那么出現(xiàn)緩存穿透的時候需要怎么應(yīng)對呢？

1）最基本的方式就是做好參數(shù)校檢，比如不合法的請求就直接拋出異常信息給客戶端，就比如設(shè)置查詢條件id不能小于0或者傳入郵箱格式不正確時直接返回錯誤消息給客戶端。但是這樣還是會出現(xiàn)緩存穿透的現(xiàn)象。那么還可以通過下面幾個方案來解決：

2）緩存無效的key，如果數(shù)據(jù)庫和緩存都找不到某個key的數(shù)據(jù)，就直接寫一個到redis中并設(shè)置它的過期時間 set key value EX 10086。這種方式可以解決請求的key變化不頻繁的情況，如果遇到專門的黑客攻擊就不能解決這個情況。但是如果依然想用這個方法的話，那么在設(shè)置過期時間的時候，時間短一點，比如是一分鐘。多說一句設(shè)置key的格式一般是：表名：列名：主鍵名：主鍵。

3）利用布隆過濾器：布隆過濾器是一個非常神奇的數(shù)據(jù)結(jié)構(gòu)，通過這個過濾器可以幫助我們非常方便的去判斷一個給定的數(shù)據(jù)是否存在于海量的數(shù)據(jù)當(dāng)中。所以布隆過濾器在針對數(shù)據(jù)去重和驗證數(shù)據(jù)的合法性時是非常有用的，布隆過濾器的實質(zhì)就是一個bit（位）數(shù)組。也就是說每一個存進的數(shù)據(jù)都僅僅只占一位，在數(shù)據(jù)結(jié)構(gòu)上來說相當(dāng)于List、Map、Set等數(shù)據(jù)結(jié)構(gòu)，但是占用的空間更少而且效率更高，但是缺點是它返回的值是概率性的，并不是多么的準(zhǔn)確。當(dāng)一個元素加入到布隆過濾器的時候：1.使用布隆過濾器當(dāng)中的哈希函數(shù)對元素值進行計算，得到哈希值。2.根據(jù)得到的哈希值，在位數(shù)組中把對應(yīng)的下標(biāo)改為1。那么設(shè)置完成之后，我們要怎么判斷一個元素是否存在于布隆過濾器當(dāng)中呢？

首先我們要根據(jù)給定的元素再次進行hash計算；得到值之后判斷數(shù)組中的每個元素是否都為1，如果值都為1的話，那么說明這個值在過濾器當(dāng)中，如果不為1的話，就說明不再過濾器當(dāng)中。

舉個非常簡單的例子

如上圖所示，當(dāng)字符串要加入到布隆過濾器當(dāng)中時，該事務(wù)首先由多個哈希函數(shù)生成不同的哈希值，然后在對應(yīng)的位數(shù)組的下標(biāo)的元素設(shè)置位1，當(dāng)二次存儲相同的字符串時，因為先前的對應(yīng)位置已經(jīng)存在，所以在去重的時候非常方便。如果我們需要判斷某個字符串是否在布隆過濾器當(dāng)中時，只需要對給定的字符串再次進行相同的哈希計算，得到的值判斷是否為1，從而判斷數(shù)據(jù)是否存在于布隆過濾器當(dāng)中，那么假如布隆過濾器說明一個數(shù)據(jù)存在時，很小的概率會誤判，但是如果說明一個數(shù)據(jù)不存在時，那么一定是不存在的。

那么通過這個原理，利用redis布隆過濾器來將所有可能存在請求的值放在布隆過濾器當(dāng)中，當(dāng)用戶請求時，直接判斷用戶發(fā)送來的請求是否存在于布隆過濾器中，不存在的話，直接返回請求參數(shù)錯誤信息給客戶，存在的話就繼續(xù)往下面走流程。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。