# 前言

設(shè)計(jì)一個(gè)緩存系統(tǒng)扮宠，不得不要考慮的問(wèn)題就是：緩存穿透、緩存擊穿與失效時(shí)的雪崩效應(yīng)狐榔。

# 緩存穿透

緩存穿透是指查詢(xún)一個(gè)一定不存在的數(shù)據(jù)坛增，由于緩存是不命中時(shí)被動(dòng)寫(xiě)的获雕，并且出于容錯(cuò)考慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫(xiě)入緩存轿偎，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到存儲(chǔ)層去查詢(xún)典鸡，失去了緩存的意義。

在流量大時(shí)坏晦，可能DB就掛掉了萝玷，要是有人利用不存在的key頻繁攻擊我們的應(yīng)用，這就是漏洞昆婿。

# 解決方案

有很多種方法可以有效地解決緩存穿透問(wèn)題球碉，最常見(jiàn)的則是采用布隆過(guò)濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bitmap中仓蛆，一個(gè)一定不存在的數(shù)據(jù)會(huì)被 這個(gè)bitmap攔截掉睁冬，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢(xún)壓力。

另外也有一個(gè)更為簡(jiǎn)單粗暴的方法（我們采用的就是這種）看疙，如果一個(gè)查詢(xún)返回的數(shù)據(jù)為空（不管是數(shù) 據(jù)不存在豆拨，還是系統(tǒng)故障），我們?nèi)匀话堰@個(gè)空結(jié)果進(jìn)行緩存能庆，但它的過(guò)期時(shí)間會(huì)很短施禾，最長(zhǎng)不超過(guò)五分鐘。

# 緩存雪崩

緩存雪崩是指在我們?cè)O(shè)置緩存時(shí)采用了相同的過(guò)期時(shí)間搁胆，導(dǎo)致緩存在某一時(shí)刻同時(shí)失效弥搞，請(qǐng)求全部轉(zhuǎn)發(fā)到DB，DB瞬時(shí)壓力過(guò)重雪崩渠旁。

# 解決方案

緩存失效時(shí)的雪崩效應(yīng)對(duì)底層系統(tǒng)的沖擊非撑世可怕。大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖或者隊(duì)列的方式保證緩存的單線(xiàn) 程（進(jìn)程）寫(xiě)顾腊，從而避免失效時(shí)大量的并發(fā)請(qǐng)求落到底層存儲(chǔ)系統(tǒng)上粤铭。

這里分享一個(gè)簡(jiǎn)單方案就是講緩存失效時(shí)間分散開(kāi)，比如我們可以在原有的失效時(shí)間基礎(chǔ)上增加一個(gè)隨機(jī)值杂靶，比如1-5分鐘隨機(jī)承耿，這樣每一個(gè)緩存的過(guò)期時(shí)間的重復(fù)率就會(huì)降低，就很難引發(fā)集體失效的事件伪煤。

# 緩存擊穿

對(duì)于一些設(shè)置了過(guò)期時(shí)間的key，如果這些key可能會(huì)在某些時(shí)間點(diǎn)被超高并發(fā)地訪(fǎng)問(wèn)凛辣，是一種非潮Ъ龋“熱點(diǎn)”的數(shù)據(jù)。這個(gè)時(shí)候扁誓，需要考慮一個(gè)問(wèn)題：緩存被“擊穿”的問(wèn)題防泵，這個(gè)和緩存雪崩的區(qū)別在于這里針對(duì)某一key緩存蚀之，前者則是很多key。

緩存在某個(gè)時(shí)間點(diǎn)過(guò)期的時(shí)候捷泞，恰好在這個(gè)時(shí)間點(diǎn)對(duì)這個(gè)Key有大量的并發(fā)請(qǐng)求過(guò)來(lái)足删，這些請(qǐng)求發(fā)現(xiàn)緩存過(guò)期一般都會(huì)從后端DB加載數(shù)據(jù)并回射到緩存，這個(gè)時(shí)候大并發(fā)的請(qǐng)求可能會(huì)瞬間把后端DB壓垮锁右。

# 解決方案

1.使用互斥鎖(mutex key)

業(yè)界比較常用的做法失受，是使用mutex。簡(jiǎn)單地來(lái)說(shuō)咏瑟，就是在緩存失效的時(shí)候（判斷拿出來(lái)的值為空）拂到，不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者M(jìn)emcache的ADD）去set一個(gè)mutex key码泞，當(dāng)操作返回成功時(shí)兄旬，再進(jìn)行l(wèi)oad db的操作并回設(shè)緩存；否則余寥，就重試整個(gè)get緩存的方法领铐。

SETNX，是「SET if Not eXists」的縮寫(xiě)宋舷，也就是只有不存在的時(shí)候才設(shè)置绪撵，可以利用它來(lái)實(shí)現(xiàn)鎖的效果。在redis2.6.1之前版本未實(shí)現(xiàn)setnx的過(guò)期時(shí)間肥缔，所以這里給出兩種版本代碼參考：

//2.6.1前單機(jī)版本鎖

String get(String key) {?

? String value = redis.get(key);?

? if (value? == null) {?

? ? if (redis.setnx(key_mutex, "1")) {?

? ? ? ? // 3 min timeout to avoid mutex holder crash?

? ? ? ? redis.expire(key_mutex, 3 * 60)?

? ? ? ? value = db.get(key);?

? ? ? ? redis.set(key, value);?

? ? ? ? redis.delete(key_mutex);?

? ? } else {?

? ? ? ? //其他線(xiàn)程休息50毫秒后重試?

? ? ? ? Thread.sleep(50);?

? ? ? ? get(key);?

? ? }?

? }?

}

新版本代碼：

public String get(key) {

? ? ? String value = redis.get(key);

? ? ? if (value == null) { //代表緩存值過(guò)期

? ? ? ? ? //設(shè)置3min的超時(shí)莲兢，防止del操作失敗的時(shí)候，下次緩存過(guò)期一直不能load db

? ? ? ? ? if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {? //代表設(shè)置成功

? ? ? ? ? ? ? value = db.get(key);

? ? ? ? ? ? ? ? ? ? ? redis.set(key, value, expire_secs);

? ? ? ? ? ? ? ? ? ? ? redis.del(key_mutex);

? ? ? ? ? ? ? } else {? //這個(gè)時(shí)候代表同時(shí)候的其他線(xiàn)程已經(jīng)load db并回設(shè)到緩存了续膳，這時(shí)候重試獲取緩存值即可

? ? ? ? ? ? ? ? ? ? ? sleep(50);

? ? ? ? ? ? ? ? ? ? ? get(key);? //重試

? ? ? ? ? ? ? }

? ? ? ? ? } else {

? ? ? ? ? ? ? return value;? ? ?

? ? ? ? ? }

}

memcache代碼：

if (memcache.get(key) == null) {?

? ? // 3 min timeout to avoid mutex holder crash?

? ? if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {?

? ? ? ? value = db.get(key);?

? ? ? ? memcache.set(key, value);?

? ? ? ? memcache.delete(key_mutex);?

? ? } else {?

? ? ? ? sleep(50);?

? ? ? ? retry();?

? ? }?

}

2. "提前"使用互斥鎖(mutex key)

在value內(nèi)部設(shè)置1個(gè)超時(shí)值(timeout1), timeout1比實(shí)際的memcache timeout(timeout2)小改艇。

當(dāng)從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過(guò)期時(shí)候，馬上延長(zhǎng)timeout1并重新設(shè)置到cache坟岔。然后再?gòu)臄?shù)據(jù)庫(kù)加載數(shù)據(jù)并設(shè)置到cache中谒兄。

偽代碼如下：

v = memcache.get(key);?

if (v == null) {?

? ? if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {?

? ? ? ? value = db.get(key);?

? ? ? ? memcache.set(key, value);?

? ? ? ? memcache.delete(key_mutex);?

? ? } else {?

? ? ? ? sleep(50);?

? ? ? ? retry();?

? ? }?

} else {?

? ? if (v.timeout <= now()) {?

? ? ? ? if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {?

? ? ? ? ? ? // extend the timeout for other threads?

? ? ? ? ? ? v.timeout += 3 * 60 * 1000;?

? ? ? ? ? ? memcache.set(key, v, KEY_TIMEOUT * 2);

? ? ? ? ? ? // load the latest value from db?

? ? ? ? ? ? v = db.get(key);?

? ? ? ? ? ? v.timeout = KEY_TIMEOUT;?

? ? ? ? ? ? memcache.set(key, value, KEY_TIMEOUT * 2);?

? ? ? ? ? ? memcache.delete(key_mutex);?

? ? ? ? } else {?

? ? ? ? ? ? sleep(50);?

? ? ? ? ? ? retry();?

? ? ? ? }?

? ? }?

}

3. "永遠(yuǎn)不過(guò)期"

這里的“永遠(yuǎn)不過(guò)期”包含兩層意思：

(1) 從redis上看，確實(shí)沒(méi)有設(shè)置過(guò)期時(shí)間社付，這就保證了承疲，不會(huì)出現(xiàn)熱點(diǎn)key過(guò)期問(wèn)題，也就是“物理”不過(guò)期鸥咖。

(2) 從功能上看燕鸽，如果不過(guò)期，那不就成靜態(tài)的了嗎啼辣？所以我們把過(guò)期時(shí)間存在key對(duì)應(yīng)的value里啊研，如果發(fā)現(xiàn)要過(guò)期了，通過(guò)一個(gè)后臺(tái)的異步線(xiàn)程進(jìn)行緩存的構(gòu)建，也就是“邏輯”過(guò)期

從實(shí)戰(zhàn)看党远，這種方法對(duì)于性能非常友好削解，唯一不足的就是構(gòu)建緩存時(shí)候，其余線(xiàn)程(非構(gòu)建緩存的線(xiàn)程)可能訪(fǎng)問(wèn)的是老數(shù)據(jù)沟娱，但是對(duì)于一般的互聯(lián)網(wǎng)功能來(lái)說(shuō)這個(gè)還是可以忍受氛驮。

String get(final String key) {?

? ? ? ? V v = redis.get(key);?

? ? ? ? String value = v.getValue();?

? ? ? ? long timeout = v.getTimeout();?

? ? ? ? if (v.timeout <= System.currentTimeMillis()) {?

? ? ? ? ? ? // 異步更新后臺(tái)異常執(zhí)行?

? ? ? ? ? ? threadPool.execute(new Runnable() {?

? ? ? ? ? ? ? ? public void run() {?

? ? ? ? ? ? ? ? ? ? String keyMutex = "mutex:" + key;?

? ? ? ? ? ? ? ? ? ? if (redis.setnx(keyMutex, "1")) {?

? ? ? ? ? ? ? ? ? ? ? ? // 3 min timeout to avoid mutex holder crash?

? ? ? ? ? ? ? ? ? ? ? ? redis.expire(keyMutex, 3 * 60);?

? ? ? ? ? ? ? ? ? ? ? ? String dbValue = db.get(key);?

? ? ? ? ? ? ? ? ? ? ? ? redis.set(key, dbValue);?

? ? ? ? ? ? ? ? ? ? ? ? redis.delete(keyMutex);?

? ? ? ? ? ? ? ? ? ? }?

? ? ? ? ? ? ? ? }?

? ? ? ? ? ? });?

? ? ? ? }?

? ? ? ? return value;?

}

4. 資源保護(hù)

采用netflix的hystrix，可以做資源的隔離保護(hù)主線(xiàn)程池济似，如果把這個(gè)應(yīng)用到緩存的構(gòu)建也未嘗不可矫废。

四種解決方案：沒(méi)有最佳只有最合適

解決方案

優(yōu)點(diǎn)

缺點(diǎn)

簡(jiǎn)單分布式鎖(Tim yang)

1. 思路簡(jiǎn)單

2. 保證一致性

1. 代碼復(fù)雜度增大

2. 存在死鎖的風(fēng)險(xiǎn)

3. 存在線(xiàn)程池阻塞的風(fēng)險(xiǎn)

加另外一個(gè)過(guò)期時(shí)間(Tim yang)

1. 保證一致性

同上

不過(guò)期(本文)

1. 異步構(gòu)建緩存，不會(huì)阻塞線(xiàn)程池

1. 不保證一致性碱屁。

2. 代碼復(fù)雜度增大(每個(gè)value都要維護(hù)一個(gè)timekey)磷脯。

3. 占用一定的內(nèi)存空間(每個(gè)value都要維護(hù)一個(gè)timekey)。

資源隔離組件hystrix(本文)

1. hystrix技術(shù)成熟娩脾，有效保證后端赵誓。

2. hystrix監(jiān)控強(qiáng)大。

1. 部分訪(fǎng)問(wèn)存在降級(jí)策略柿赊。

# 總結(jié)

針對(duì)業(yè)務(wù)系統(tǒng)俩功，永遠(yuǎn)都是具體情況具體分析，沒(méi)有最好碰声，只有最合適诡蜓。

最后，對(duì)于緩存系統(tǒng)常見(jiàn)的緩存滿(mǎn)了和數(shù)據(jù)丟失問(wèn)題胰挑，需要根據(jù)具體業(yè)務(wù)分析蔓罚，通常我們采用LRU策略處理溢出，Redis的RDB和AOF持久化策略來(lái)保證一定情況下的數(shù)據(jù)安全瞻颂。