最近都沒(méi)看Redis，現(xiàn)在回來(lái)溫習(xí)下，現(xiàn)在從Redis的三大緩存開(kāi)始重新探一探有多深有多淺(^▽^)

[[341225]]

讓我來(lái)開(kāi)始知識(shí)的醍醐灌頂把！是時(shí)候表演真正的技術(shù)了。（嗶嗶嗶嗶....）

[[341226]]

鐵子們，看在二哈這么賣(mài)力的份上，如果覺(jué)得本文對(duì)你有幫助的話，請(qǐng)動(dòng)動(dòng)你的小手，比個(gè)❥(^_-)愛(ài)心推薦喲。

接下來(lái)就開(kāi)始我們的Redis的三大緩存問(wèn)題之旅，讓我們坐上二哈的小飛船游一游這圣女峰。

[[341227]]

在Redis緩存中有三個(gè)必須要知道概念：緩存穿透、緩存擊穿和緩存雪崩。

緩存穿透

那什么是緩存穿透，它就是指當(dāng)用戶(hù)在查詢(xún)一條數(shù)據(jù)的時(shí)候，而此時(shí)數(shù)據(jù)庫(kù)和緩存卻沒(méi)有關(guān)于這條數(shù)據(jù)的任何記錄，而這條數(shù)據(jù)在緩存中沒(méi)找到就會(huì)向數(shù)據(jù)庫(kù)請(qǐng)求獲取數(shù)據(jù)。它拿不到數(shù)據(jù)時(shí)，是會(huì)一直查詢(xún)數(shù)據(jù)庫(kù)，這樣會(huì)對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)造成很大的壓力。

如：用戶(hù)查詢(xún)一個(gè) id = -1 的商品信息，一般數(shù)據(jù)庫(kù) id 值都是從 1 開(kāi)始自增，很明顯這條信息是不在數(shù)據(jù)庫(kù)中，當(dāng)沒(méi)有信息返回時(shí)，會(huì)一直向數(shù)據(jù)庫(kù)查詢(xún)，給當(dāng)前數(shù)據(jù)庫(kù)的造成很大的訪問(wèn)壓力。

這時(shí)候我們要想一想，該如何解決這個(gè)問(wèn)題呢？o(╥﹏╥)o

一般我們可以想到從緩存開(kāi)始出發(fā)，想如果我們給緩存設(shè)置一個(gè)如果當(dāng)前數(shù)據(jù)庫(kù)不存在的信息，把它緩存成一個(gè)空對(duì)象，返回給用戶(hù)。

^_^沒(méi)錯(cuò)，這是一個(gè)解決方案，也就是我們常說(shuō)的緩存空對(duì)象（代碼維護(hù)簡(jiǎn)單，但是效果不是很好）。

Redis 也為我們提供了一種解決方案，那就是布隆過(guò)濾器（代碼維護(hù)比較復(fù)雜，效果挺好的）。

那接下來(lái)，二哈先解釋下這兩種方案：

緩存空對(duì)象

那什么是緩存空對(duì)象呀，二哈！別急，緩存空對(duì)象它就是指一個(gè)請(qǐng)求發(fā)送過(guò)來(lái)，如果此時(shí)緩存中和數(shù)據(jù)庫(kù)都不存在這個(gè)請(qǐng)求所要查詢(xún)的相關(guān)信息，那么數(shù)據(jù)庫(kù)就會(huì)返回一個(gè)空對(duì)象，并將這個(gè)空對(duì)象和請(qǐng)求關(guān)聯(lián)起來(lái)存到緩存中，當(dāng)下次還是這個(gè)請(qǐng)求過(guò)來(lái)的時(shí)候，這時(shí)緩存就會(huì)命中，就直接從緩存中返回這個(gè)空對(duì)象，這樣可以減少訪問(wèn)數(shù)據(jù)庫(kù)的壓力，提高當(dāng)前數(shù)據(jù)庫(kù)的訪問(wèn)性能。我們接下來(lái)可以看下面這個(gè)流程呀~

這時(shí)候，我們就會(huì)問(wèn)了呀 ~，如果大量不存在的請(qǐng)求過(guò)來(lái)，那么這時(shí)候緩存豈不是會(huì)緩存許多空對(duì)象了嗎~~~

沒(méi)錯(cuò)哦！這也是使用緩存空對(duì)象會(huì)導(dǎo)致的一個(gè)問(wèn)題：如果時(shí)間一長(zhǎng)這樣會(huì)導(dǎo)致緩存中存在大量空對(duì)象，這樣不僅會(huì)占用許多的內(nèi)存空間，還會(huì)浪費(fèi)許多資源呀！。那這有沒(méi)有什么可以解決的方法呢？我們來(lái)想一想：我們可以將這些對(duì)象在一段時(shí)間之后清理下不久可以了嗎 ~

嗯嗯，沒(méi)錯(cuò)！在想想 Redis 里是不是給我們提供了有關(guān)過(guò)期時(shí)間的命令呀(^▽^)，這樣我們可以在設(shè)置空對(duì)象的時(shí)間，順便設(shè)置一個(gè)過(guò)期時(shí)間，就可以解決個(gè)問(wèn)題了呀！

號(hào)外號(hào)外，大家可以關(guān)注公眾號(hào)Java技術(shù)棧在后臺(tái)回復(fù)福利可以獲取一份我整理的最新面試題資料。

setex key seconds valule:設(shè)置鍵值對(duì)的同時(shí)指定過(guò)期時(shí)間(s) 

在Java 中直接調(diào)用 API 操作即可：

redisCache.put(Integer.toString(id), null, 60) //過(guò)期時(shí)間為 60s 

布隆過(guò)濾器

那布隆過(guò)濾器是不是不是一個(gè)過(guò)濾器，過(guò)濾東西的呀！哎呀，你太聰明了，沒(méi)錯(cuò)它就是用來(lái)過(guò)濾東西的，它是一種基于概率的數(shù)據(jù)結(jié)構(gòu)，主要使用愛(ài)判斷當(dāng)前某個(gè)元素是否在該集合中，運(yùn)行速度快。我們也可以簡(jiǎn)單理解為是一個(gè)不怎么精確的 set 結(jié)構(gòu)（set 具有去重的效果）。

但是有個(gè)小問(wèn)題是：當(dāng)你使用它的 contains 方法去判斷某個(gè)對(duì)象是否存在時(shí)，它可能會(huì)誤判。也就是說(shuō)布隆過(guò)濾器不是特別不精確，但是只要參數(shù)設(shè)置的合理，它的精確度可以控制的相對(duì)足夠精確，只會(huì)有小小的誤判概率（這是可以接受的呀 ~）。當(dāng)布隆過(guò)濾器說(shuō)某個(gè)值存在時(shí)，這個(gè)值可能不存在；當(dāng)它說(shuō)不存在時(shí)，那就肯定不存在。

這里有個(gè)典型的例子呀，來(lái)自錢(qián)大：

打個(gè)比方，當(dāng)它說(shuō)不認(rèn)識(shí)你時(shí)，肯定就不認(rèn)識(shí)；當(dāng)它說(shuō)見(jiàn)過(guò)你時(shí)，可能根本就沒(méi)見(jiàn)過(guò)面，不過(guò)因?yàn)槟愕哪樃J(rèn)識(shí)的人中某臉比較相似 (某些熟臉的系數(shù)組合)，所以誤判以前見(jiàn)過(guò)你。

在上面的使用場(chǎng)景中，布隆過(guò)濾器能準(zhǔn)確過(guò)濾掉那些已經(jīng)看過(guò)的內(nèi)容，那些沒(méi)有看過(guò)的新內(nèi)容，它也會(huì)過(guò)濾掉極小一部分 (誤判)，但是絕大多數(shù)新內(nèi)容它都能準(zhǔn)確識(shí)別。這樣就可以完全保證推薦給用戶(hù)的內(nèi)容都是無(wú)重復(fù)的。

說(shuō)了這么久，那布隆過(guò)濾器到底有什么特點(diǎn)呢：

特點(diǎn)嗎，多多來(lái)讓一個(gè)個(gè)跟你吹吹（吹到你懷疑人生(≧∇≦)ﾉ）

1.  一個(gè)非常大的二進(jìn)制位數(shù)組（數(shù)組中只存在 0 和 1）
2.  擁有若干個(gè)哈希函數(shù)（Hash Function）
3.  在空間效率和查詢(xún)效率都非常高
4.  布隆過(guò)濾器不會(huì)提供刪除方法，在代碼維護(hù)上比較困難。

每個(gè)布隆過(guò)濾器對(duì)應(yīng)到 Redis 的數(shù)據(jù)結(jié)構(gòu)里面就是一個(gè)大型的位數(shù)組和幾個(gè)不一樣的無(wú)偏 hash 函數(shù)。所謂無(wú)偏就是能夠把元素的 hash 值算得比較均勻。具體可以參考這篇文章：布隆過(guò)濾器到底有什么用？。

向布隆過(guò)濾器中添加 key 時(shí)，會(huì)使用多個(gè) hash 函數(shù)對(duì) key 進(jìn)行 hash 算得一個(gè)整數(shù)索引值然后對(duì)位數(shù)組長(zhǎng)度進(jìn)行取模運(yùn)算得到一個(gè)位置，每個(gè) hash 函數(shù)都會(huì)算得一個(gè)不同的位置。再把位數(shù)組的這幾個(gè)位置都置為 1 就完成了 add 操作。（ 每一個(gè) key 都通過(guò)若干的hash函數(shù)映射到一個(gè)巨大位數(shù)組上，映射成功后，會(huì)在把位數(shù)組上對(duì)應(yīng)的位置改為1。）

那為什么布隆過(guò)濾器會(huì)存在誤判率呢？

誤判嗎？人生哪有不摔跤，只要鋤頭揮得好，照樣能挖到。（咳咳咳，說(shuō)偏了...）

其實(shí)它會(huì)誤判是如下這個(gè)情況：

當(dāng) key1 和 key2 映射到位數(shù)組上的位置為 1 時(shí)，假設(shè)這時(shí)候來(lái)了個(gè) key3，要查詢(xún)是不是在里面，恰好 key3 對(duì)應(yīng)位置也映射到了這之間，那么布隆過(guò)濾器會(huì)認(rèn)為它是存在的，這時(shí)候就會(huì)產(chǎn)生誤判（因?yàn)槊髅?key3 是不在的）。

O(∩_∩)O哈哈~，這時(shí)候你會(huì)問(wèn)了：如何提高布隆過(guò)濾器的準(zhǔn)確率呢？

要提高布隆過(guò)濾器的準(zhǔn)確率，就要說(shuō)到影響它的三個(gè)重要因素：

1.  哈希函數(shù)的好壞
2.  存儲(chǔ)空間大小
3.  哈希函數(shù)個(gè)數(shù)

hash函數(shù)的設(shè)計(jì)也是一個(gè)十分重要的問(wèn)題，對(duì)于好的hash函數(shù)能大大降低布隆過(guò)濾器的誤判率。

（這就好比優(yōu)秀的配件之所以能夠運(yùn)行這么順暢就在于其內(nèi)部設(shè)計(jì)的得當(dāng)。）

同時(shí)，對(duì)于一個(gè)布隆過(guò)濾器來(lái)說(shuō)，如果其位數(shù)組越大的話，那么每個(gè)key通過(guò)hash函數(shù)映射的位置會(huì)變得稀疏許多，不會(huì)那么緊湊，有利于提高布隆過(guò)濾器的準(zhǔn)確率。

同時(shí)，對(duì)于一個(gè)布隆過(guò)濾器來(lái)說(shuō)，如果key通過(guò)許多hash函數(shù)映射，那么在位數(shù)組上就會(huì)有許多位置有標(biāo)志，這樣當(dāng)用戶(hù)查詢(xún)的時(shí)候，在通過(guò)布隆過(guò)濾器來(lái)找的時(shí)候，誤判率也會(huì)相應(yīng)降低。

對(duì)于其內(nèi)部原理，有興趣的同學(xué)可以看看關(guān)于布隆過(guò)濾的數(shù)學(xué)知識(shí)，里面有關(guān)于它的設(shè)計(jì)算法和數(shù)學(xué)知識(shí)。（其實(shí)也挺簡(jiǎn)單~）

緩存擊穿

緩存擊穿是指有某個(gè)key經(jīng)常被查詢(xún)，經(jīng)常被用戶(hù)特殊關(guān)懷，用戶(hù)非常 love 它 (^▽^)，也就類(lèi)比“熟客” 或者 一個(gè)key經(jīng)常不被訪問(wèn)。推薦閱讀：緩存三大問(wèn)題及解決方案。

但是這時(shí)候，如果這個(gè)key在緩存的過(guò)期時(shí)間失效的時(shí)候或者這是個(gè)冷門(mén)key時(shí)，這時(shí)候突然有大量有關(guān)這個(gè)key的訪問(wèn)請(qǐng)求，這樣會(huì)導(dǎo)致大并發(fā)請(qǐng)求直接穿透緩存，請(qǐng)求數(shù)據(jù)庫(kù)，瞬間對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)壓力增大。

歸納起來(lái)：造成緩存擊穿的原因有兩個(gè)。

（1）一個(gè)“冷門(mén)”key，突然被大量用戶(hù)請(qǐng)求訪問(wèn)。

（2）一個(gè)“熱門(mén)”key，在緩存中時(shí)間恰好過(guò)期，這時(shí)有大量用戶(hù)來(lái)進(jìn)行訪問(wèn)。

對(duì)于緩存擊穿的問(wèn)題：我們常用的解決方案是加鎖。對(duì)于key過(guò)期的時(shí)候，當(dāng)key要查詢(xún)數(shù)據(jù)庫(kù)的時(shí)候加上一把鎖，這時(shí)只能讓第一個(gè)請(qǐng)求進(jìn)行查詢(xún)數(shù)據(jù)庫(kù)，然后把從數(shù)據(jù)庫(kù)中查詢(xún)到的值存儲(chǔ)到緩存中，對(duì)于剩下的相同的key，可以直接從緩存中獲取即可。

如果我們是在單機(jī)環(huán)境下：直接使用常用的鎖即可（如：Lock、Synchronized等），在分布式環(huán)境下我們可以使用分布式鎖，如：基于數(shù)據(jù)庫(kù)、基于Redis 或者 zookeeper 的分布式鎖。

緩存雪崩

緩存雪崩是指在某一個(gè)時(shí)間段內(nèi)，緩存集中過(guò)期失效，如果這個(gè)時(shí)間段內(nèi)有大量請(qǐng)求，而查詢(xún)數(shù)據(jù)量巨大，所有的請(qǐng)求都會(huì)達(dá)到存儲(chǔ)層，存儲(chǔ)層的調(diào)用量會(huì)暴增，引起數(shù)據(jù)庫(kù)壓力過(guò)大甚至宕機(jī)。

原因：

1.  Redis突然宕機(jī)
2.  大部分?jǐn)?shù)據(jù)失效

舉個(gè)例子理解下吧：

比如我們基本上都經(jīng)歷過(guò)購(gòu)物狂歡節(jié)，假設(shè)商家舉辦 23:00-24:00 商品打骨折促銷(xiāo)活動(dòng)。程序小哥哥在設(shè)計(jì)的時(shí)候，在 23:00 把商家打骨折的商品放到緩存中，并通過(guò)redis的expire設(shè)置了過(guò)期時(shí)間為1小時(shí)。

這個(gè)時(shí)間段許多用戶(hù)訪問(wèn)這些商品信息、購(gòu)買(mǎi)等等。但是剛好到了24:00點(diǎn)的時(shí)候，恰好還有許多用戶(hù)在訪問(wèn)這些商品，這時(shí)候?qū)@些商品的訪問(wèn)都會(huì)落到數(shù)據(jù)庫(kù)上，導(dǎo)致數(shù)據(jù)庫(kù)要抗住巨大的壓力，稍有不慎會(huì)導(dǎo)致，數(shù)據(jù)庫(kù)直接宕機(jī)（over）。

當(dāng)商品沒(méi)有失效的時(shí)候是這樣的：

當(dāng)緩存GG（失效）的時(shí)候卻是這樣的：

對(duì)于緩存雪崩有以下解決方案：

（1）redis高可用

Redis有可能掛掉，多增加幾臺(tái)redis實(shí)例，（一主多從或者多主多從），這樣一臺(tái)掛掉之后其他的還可以繼續(xù)工作，其實(shí)就是搭建的集群。

（2）限流降級(jí)

在緩存失效后，通過(guò)加鎖或者隊(duì)列來(lái)控制讀數(shù)據(jù)庫(kù)寫(xiě)緩存的線程數(shù)量，對(duì)某個(gè)key只允許一個(gè)線程查詢(xún)數(shù)據(jù)和寫(xiě)緩存，其他線程等待。

（3）數(shù)據(jù)預(yù)熱

數(shù)據(jù)加熱的含義就是在正式部署之前，我先把可能的數(shù)據(jù)先預(yù)先訪問(wèn)一遍，這樣部分可能大量訪問(wèn)的數(shù)據(jù)就會(huì)加載到緩存中。在即將發(fā)生大并發(fā)訪問(wèn)前手動(dòng)觸發(fā)加載緩存不同的key。

（4）不同的過(guò)期時(shí)間

設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻。