主頁(yè) > 知識(shí)庫(kù) > Redis緩存穿透出現(xiàn)原因及解決方案

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

熱門標(biāo)簽:地圖標(biāo)注工廠入駐 400電話辦理的口碑 高碑店市地圖標(biāo)注app 四川穩(wěn)定外呼系統(tǒng)軟件 南京手機(jī)外呼系統(tǒng)廠家 b2b外呼系統(tǒng) 一個(gè)地圖標(biāo)注多少錢 廊坊外呼系統(tǒng)在哪買 臺(tái)灣電銷

在并發(fā)式的項(xiàng)目當(dāng)中,一定要考慮一個(gè)緩存穿透的情況。那么什么是緩存穿透呢?簡(jiǎn)單的說(shuō)來(lái),就是當(dāng)大量請(qǐng)求的key根本不在緩存當(dāng)中,所以導(dǎo)致了請(qǐng)求直接到了數(shù)據(jù)庫(kù)上,根本沒(méi)有經(jīng)過(guò)緩存這一層。比如一個(gè)黑客故意制造我們緩存中不存在的key發(fā)送大量的請(qǐng)求,就會(huì)導(dǎo)致請(qǐng)求直接落到數(shù)據(jù)庫(kù)上。

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

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

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

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

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

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

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

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

舉個(gè)非常簡(jiǎn)單的例子

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

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

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

您可能感興趣的文章:
  • Redis分析慢查詢操作的實(shí)例教程
  • 淺析JavaWeb項(xiàng)目架構(gòu)之Redis分布式日志隊(duì)列
  • java獲取redis日志信息與動(dòng)態(tài)監(jiān)控信息的方法
  • 如何高效使用Redis作為L(zhǎng)RU緩存
  • Linux安裝Redis實(shí)現(xiàn)過(guò)程及報(bào)錯(cuò)解決方案
  • spring boot+redis 監(jiān)聽(tīng)過(guò)期Key的操作方法
  • Redis面試必會(huì)的題目
  • 在Docker中使用Redis的步驟詳解
  • SpringBoot2.3整合redis緩存自定義序列化的實(shí)現(xiàn)
  • Redis 執(zhí)行性能測(cè)試
  • Redis緩存常用4種策略原理詳解
  • 詳解Redis的慢查詢?nèi)罩?/li>

標(biāo)簽:畢節(jié) 拉薩 南寧 河源 泰州 定州 伊春 甘南

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《Redis緩存穿透出現(xiàn)原因及解決方案》,本文關(guān)鍵詞  Redis,緩存,穿透,出現(xiàn),原因,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《Redis緩存穿透出現(xiàn)原因及解決方案》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于Redis緩存穿透出現(xiàn)原因及解決方案的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章