1 前言

昨天晚上接到阿里的電面電話(huà)，過(guò)程中就問(wèn)到了關(guān)于緩存相關(guān)的問(wèn)題。

雖然以前接觸過(guò)，多多少少了解了一些。但是之前自己并沒(méi)有好好記錄這些內(nèi)容，在真正面試的時(shí)候，并沒(méi)有回答得出來(lái)。今天記錄一下，長(zhǎng)長(zhǎng)記性。

在我們的平常的項(xiàng)目中多多少少都會(huì)使用到緩存，因?yàn)橐恍?shù)據(jù)我們沒(méi)有必要每次查詢(xún)的時(shí)候都去查詢(xún)到數(shù)據(jù)庫(kù)。

特別是高 QPS 的系統(tǒng)，每次都去查詢(xún)數(shù)據(jù)庫(kù)，對(duì)于你的數(shù)據(jù)庫(kù)來(lái)說(shuō)將是災(zāi)難。

今天我們不牽涉多級(jí)緩存的知識(shí)，就把系統(tǒng)使用到的緩存方案，不管是一級(jí)還是多級(jí)的都統(tǒng)稱(chēng)為緩存，主要是為了講述使用緩存的時(shí)候可能會(huì)遇到的一些問(wèn)題以及一些解決辦法。

我們使用緩存時(shí)，我們的業(yè)務(wù)系統(tǒng)大概的調(diào)用流程如下圖：


當(dāng)我們查詢(xún)一條數(shù)據(jù)時(shí)，先去查詢(xún)緩存，如果緩存有就直接返回，如果沒(méi)有就去查詢(xún)數(shù)據(jù)庫(kù)，然后返回。這種情況下就可能會(huì)出現(xiàn)一些現(xiàn)象。

2 緩存穿透

2.1 什么是緩存穿透

正常情況下，我們?nèi)ゲ樵?xún)數(shù)據(jù)都是存在。

那么請(qǐng)求去查詢(xún)一條壓根兒數(shù)據(jù)庫(kù)中根本就不存在的數(shù)據(jù)，也就是緩存和數(shù)據(jù)庫(kù)都查詢(xún)不到這條數(shù)據(jù)，但是請(qǐng)求每次都會(huì)打到數(shù)據(jù)庫(kù)上面去。

這種查詢(xún)不存在數(shù)據(jù)的現(xiàn)象我們稱(chēng)為緩存穿透。

2.2 穿透帶來(lái)的問(wèn)題

試想一下，如果有黑客會(huì)對(duì)你的系統(tǒng)進(jìn)行攻擊，拿一個(gè)不存在的id 去查詢(xún)數(shù)據(jù)，會(huì)產(chǎn)生大量的請(qǐng)求到數(shù)據(jù)庫(kù)去查詢(xún)?？赡軙?huì)導(dǎo)致你的數(shù)據(jù)庫(kù)由于壓力過(guò)大而宕掉。

2.3 解決辦法

2.3.1 緩存空值

之所以會(huì)發(fā)生穿透，就是因?yàn)榫彺嬷袥](méi)有存儲(chǔ)這些空數(shù)據(jù)的key。從而導(dǎo)致每次查詢(xún)都到數(shù)據(jù)庫(kù)去了。

那么我們就可以為這些key對(duì)應(yīng)的值設(shè)置為null 丟到緩存里面去。后面再出現(xiàn)查詢(xún)這個(gè)key 的請(qǐng)求的時(shí)候，直接返回null 。

這樣，就不用在到數(shù)據(jù)庫(kù)中去走一圈了，但是別忘了設(shè)置過(guò)期時(shí)間。

2.3.2 BloomFilter

BloomFilter 類(lèi)似于一個(gè)hbase set 用來(lái)判斷某個(gè)元素（key）是否存在于某個(gè)集合中。

這種方式在大數(shù)據(jù)場(chǎng)景應(yīng)用比較多，比如 Hbase 中使用它去判斷數(shù)據(jù)是否在磁盤(pán)上。還有在爬蟲(chóng)場(chǎng)景判斷url 是否已經(jīng)被爬取過(guò)。

這種方案可以加在第一種方案中，在緩存之前在加一層 BloomFilter ，在查詢(xún)的時(shí)候先去 BloomFilter 去查詢(xún) key 是否存在，如果不存在就直接返回，存在再走查緩存 -> 查 DB。

流程圖如下：


2.4 如何選擇

針對(duì)于一些惡意攻擊，攻擊帶過(guò)來(lái)的大量key 是不存在的，那么我們采用第一種方案就會(huì)緩存大量不存在key的數(shù)據(jù)。

此時(shí)我們采用第一種方案就不合適了，我們完全可以先對(duì)使用第二種方案進(jìn)行過(guò)濾掉這些key。

針對(duì)這種key異常多、請(qǐng)求重復(fù)率比較低的數(shù)據(jù)，我們就沒(méi)有必要進(jìn)行緩存，使用第二種方案直接過(guò)濾掉。

而對(duì)于空數(shù)據(jù)的key有限的，重復(fù)率比較高的，我們則可以采用第一種方式進(jìn)行緩存。

3 緩存擊穿

3.1 什么是擊穿

緩存擊穿是我們可能遇到的第二個(gè)使用緩存方案可能遇到的問(wèn)題。

在平常高并發(fā)的系統(tǒng)中，大量的請(qǐng)求同時(shí)查詢(xún)一個(gè) key 時(shí)，此時(shí)這個(gè)key正好失效了，就會(huì)導(dǎo)致大量的請(qǐng)求都打到數(shù)據(jù)庫(kù)上面去。這種現(xiàn)象我們稱(chēng)為緩存擊穿。

3.2 會(huì)帶來(lái)什么問(wèn)題

會(huì)造成某一時(shí)刻數(shù)據(jù)庫(kù)請(qǐng)求量過(guò)大，壓力劇增。

3.3 如何解決

上面的現(xiàn)象是多個(gè)線(xiàn)程同時(shí)去查詢(xún)數(shù)據(jù)庫(kù)的這條數(shù)據(jù)，那么我們可以在第一個(gè)查詢(xún)數(shù)據(jù)的請(qǐng)求上使用一個(gè) 互斥鎖來(lái)鎖住它。

其他的線(xiàn)程走到這一步拿不到鎖就等著，等第一個(gè)線(xiàn)程查詢(xún)到了數(shù)據(jù)，然后做緩存。后面的線(xiàn)程進(jìn)來(lái)發(fā)現(xiàn)已經(jīng)有緩存了，就直接走緩存。

4、緩存雪崩

4.1 什么是緩存雪崩

緩存雪崩的情況是說(shuō)，當(dāng)某一時(shí)刻發(fā)生大規(guī)模的緩存失效的情況，比如你的緩存服務(wù)宕機(jī)了，會(huì)有大量的請(qǐng)求進(jìn)來(lái)直接打到DB上面。結(jié)果就是DB 稱(chēng)不住，掛掉。

4.2 解決辦法

4.2.1 事前：

• 使用集群緩存，保證緩存服務(wù)的高可用

這種方案就是在發(fā)生雪崩前對(duì)緩存集群實(shí)現(xiàn)高可用，如果是使用 Redis，可以使用 主從+哨兵 ，Redis Cluster 來(lái)避免 Redis 全盤(pán)崩潰的情況。

4.2.2 事中：

• ehcache本地緩存 + Hystrix限流&降級(jí),避免MySQL被打死

使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時(shí)候，ehcache 本地緩存還能夠支撐一陣。

使用 Hystrix進(jìn)行限流 & 降級(jí) ，比如一秒來(lái)了5000個(gè)請(qǐng)求，我們可以設(shè)置假設(shè)只能有一秒 2000個(gè)請(qǐng)求能通過(guò)這個(gè)組件，那么其他剩余的 3000 請(qǐng)求就會(huì)走限流邏輯。

然后去調(diào)用我們自己開(kāi)發(fā)的降級(jí)組件（降級(jí)），比如設(shè)置的一些默認(rèn)值呀之類(lèi)的。以此來(lái)保護(hù)最后的 MySQL 不會(huì)被大量的請(qǐng)求給打死。

4.2.3 事后：

• 開(kāi)啟Redis持久化機(jī)制，盡快恢復(fù)緩存集群

一旦重啟，就能從磁盤(pán)上自動(dòng)加載數(shù)據(jù)恢復(fù)內(nèi)存中的數(shù)據(jù)。

防止雪崩方案如下圖所示：


5 解決熱點(diǎn)數(shù)據(jù)集中失效問(wèn)題

我們?cè)谠O(shè)置緩存的時(shí)候，一般會(huì)給緩存設(shè)置一個(gè)失效時(shí)間，過(guò)了這個(gè)時(shí)間，緩存就失效了。

對(duì)于一些熱點(diǎn)的數(shù)據(jù)來(lái)說(shuō)，當(dāng)緩存失效以后會(huì)存在大量的請(qǐng)求過(guò)來(lái)，然后打到數(shù)據(jù)庫(kù)去，從而可能導(dǎo)致數(shù)據(jù)庫(kù)崩潰的情況。

5.1 解決辦法

5.1.1 設(shè)置不同的失效時(shí)間

為了避免這些熱點(diǎn)的數(shù)據(jù)集中失效，那么我們?cè)谠O(shè)置緩存過(guò)期時(shí)間的時(shí)候，我們讓他們失效的時(shí)間錯(cuò)開(kāi)。

比如在一個(gè)基礎(chǔ)的時(shí)間上加上或者減去一個(gè)范圍內(nèi)的隨機(jī)值。

5.1.2 互斥鎖

結(jié)合上面的擊穿的情況，在第一個(gè)請(qǐng)求去查詢(xún)數(shù)據(jù)庫(kù)的時(shí)候?qū)λ右粋€(gè)互斥鎖，其余的查詢(xún)請(qǐng)求都會(huì)被阻塞住，直到鎖被釋放，從而保護(hù)數(shù)據(jù)庫(kù)。

但是也是由于它會(huì)阻塞其他的線(xiàn)程，此時(shí)系統(tǒng)吞吐量會(huì)下降。需要結(jié)合實(shí)際的業(yè)務(wù)去考慮是否要這么做。