緩存擊穿

緩存擊穿問題也叫熱點(diǎn)Key問題，就是一個(gè)被高并發(fā)訪問并且緩存重建業(yè)務(wù)較復(fù)雜的key突然失效了，無數(shù)的請(qǐng)求訪問會(huì)在瞬間給數(shù)據(jù)庫帶來巨大的沖擊。常見的解決方案有：

- 互斥鎖
	- 邏輯過期
	- key 永不過期
	- 接口限流

邏輯分析：假設(shè)線程1在查詢緩存之后，本來應(yīng)該去查詢數(shù)據(jù)庫，然后把這個(gè)數(shù)據(jù)重新加載到緩存的，此時(shí)只要線程1走完這個(gè)邏輯，其他線程就都能從緩存中加載這些數(shù)據(jù)了，但是假設(shè)在線程1沒有走完的時(shí)候，后續(xù)的線程2，線程3，線程4同時(shí)過來訪問當(dāng)前這個(gè)方法， 那么這些線程都不能從緩存中查詢到數(shù)據(jù)，那么他們就會(huì)同一時(shí)刻來訪問查詢緩存，都沒查到，接著同一時(shí)間去訪問數(shù)據(jù)庫，同時(shí)的去執(zhí)行數(shù)據(jù)庫代碼，對(duì)數(shù)據(jù)庫訪問壓力非常大。

解決方案一、使用鎖來解決：

因?yàn)殒i能實(shí)現(xiàn)互斥性。假設(shè)線程過來，只能一個(gè)人一個(gè)人的來訪問數(shù)據(jù)庫，從而避免對(duì)于數(shù)據(jù)庫訪問壓力過大，但這也會(huì)影響查詢的性能，因?yàn)榇藭r(shí)會(huì)讓查詢的性能從并行變成了串行，我們可以采用 tryLock 方法 + double check 來解決這樣的問題。假設(shè)現(xiàn)在線程1過來訪問，他查詢緩存沒有命中，但是此時(shí)他獲得到了鎖的資源，那么線程1就會(huì)一個(gè)人去執(zhí)行邏輯，假設(shè)現(xiàn)在線程2過來，線程2在執(zhí)行過程中，并沒有獲得到鎖，那么線程2就可以進(jìn)行到休眠，直到線程1把鎖釋放后，線程2獲得到鎖，然后再來執(zhí)行邏輯，此時(shí)就能夠從緩存中拿到數(shù)據(jù)了。

解決方案二、邏輯過期方案

方案分析：我們之所以會(huì)出現(xiàn)這個(gè)緩存擊穿問題，主要原因是在于我們對(duì)key設(shè)置了過期時(shí)間，假設(shè)我們不設(shè)置過期時(shí)間，其實(shí)就不會(huì)有緩存擊穿的問題，但是不設(shè)置過期時(shí)間，這樣數(shù)據(jù)不就一直占用我們內(nèi)存了嗎，我們可以采用邏輯過期方案。我們把過期時(shí)間設(shè)置在 redis的value中，注意：這個(gè)過期時(shí)間并不會(huì)直接作用于redis，而是我們后續(xù)通過邏輯去處理。假設(shè)線程1去查詢緩存，然后從value中判斷出來當(dāng)前的數(shù)據(jù)已經(jīng)過期了，此時(shí)線程1去獲得互斥鎖，那么其他線程會(huì)進(jìn)行阻塞，獲得了鎖的線程他會(huì)開啟一個(gè) 線程去進(jìn)行 以前的重構(gòu)數(shù)據(jù)的邏輯，直到新開的線程完成這個(gè)邏輯后，才釋放鎖， 而線程1直接進(jìn)行返回，假設(shè)現(xiàn)在線程3過來訪問，由于線程線程2持有著鎖，所以線程3無法獲得鎖，線程3也直接返回?cái)?shù)據(jù)，只有等到新開的線程2把重建數(shù)據(jù)構(gòu)建完后，其他線程才能走返回正確的數(shù)據(jù)。這種方案巧妙在于，異步的構(gòu)建緩存，缺點(diǎn)在于在構(gòu)建完緩存之前，返回的都是臟數(shù)據(jù)。

進(jìn)行對(duì)比互斥鎖方案由于保證了互斥性，所以數(shù)據(jù)一致，且實(shí)現(xiàn)簡單，因?yàn)閮H僅只需要加一把鎖而已，也沒其他的事情需要操心，所以沒有額外的內(nèi)存消耗，缺點(diǎn)在于有鎖就有死鎖問題的發(fā)生，且只能串行執(zhí)行性能肯定受到影響邏輯過期方案： 線程讀取過程中不需要等待，性能好，有一個(gè)額外的線程持有鎖去進(jìn)行重構(gòu)數(shù)據(jù)，但是在重構(gòu)數(shù)據(jù)完成前，其他的線程只能返回之前的數(shù)據(jù)，且實(shí)現(xiàn)起來麻煩。

解決方案三、永不過期 主動(dòng)更新

解決方案四、接口限流

利用互斥鎖解決緩存擊穿問題

核心思路：相較于原來從緩存中查詢不到數(shù)據(jù)后直接查詢數(shù)據(jù)庫而言，現(xiàn)在的方案是 進(jìn)行查詢之后，如果從緩存沒有查詢到數(shù)據(jù)，則進(jìn)行互斥鎖的獲取，獲取互斥鎖后，判斷是否獲得到了鎖，如果沒有獲得到，則休眠，過一會(huì)再進(jìn)行嘗試，直到獲取到鎖為止，才能進(jìn)行查詢?nèi)绻@取到了鎖的線程，再去進(jìn)行查詢，查詢后將數(shù)據(jù)寫入redis，再釋放鎖，返回?cái)?shù)據(jù)，利用互斥鎖就能保證只有一個(gè)線程去執(zhí)行操作數(shù)據(jù)庫的邏輯，防止緩存擊穿。

操作鎖的代碼：核心思路就是利用 redis 的 setnx 方法來表示獲取鎖，該方法含義是redis中如果沒有這個(gè) key，則插入成功，返回1，在 stringRedisTemplate 中返回 true， 如果有這個(gè) key 則插入失敗，則返回0，在stringRedisTemplate 返回 false，我們可以通過 true，或者是 false，來表示是否有線程成功插入 key，成功插入的 key 的線程我們認(rèn)為他就是獲得到鎖的線程。

private boolean tryLock(String key, String value, long time) {
    Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, value, time, TimeUnit.SECONDS);
    return BooleanUtil.isTrue(flag);
}
private void unlock(String key) {
    stringRedisTemplate.delete(key);
}

操作鎖要注意對(duì) value 加入標(biāo)識(shí)，在釋放鎖之前對(duì)其進(jìn)行判斷是不是自己的鎖，防止誤刪?。ㄟ€要保證判斷語句和釋放語句的原子性 可以用 lua 腳本）

核心代碼：

public Shop queryWithMutex(Long id)  {
    String key = CACHE_SHOP_KEY + id;
    // 1、從redis中查詢商鋪緩存
    String shopJson = stringRedisTemplate.opsForValue().get("key");
    // 2、判斷是否存在
    if (StrUtil.isNotBlank(shopJson)) {
        // 存在,直接返回
        return JSONUtil.toBean(shopJson, Shop.class);
    }
    //判斷命中的值是否是空值
    if (shopJson != null) {
        //返回一個(gè)錯(cuò)誤信息
        return null;
    }
    // 4.實(shí)現(xiàn)緩存重構(gòu)
    //4.1 獲取互斥鎖
    String lockKey = "lock:shop:" + id;
	long current_thread_id = Thread.currentThread().getId();
    Shop shop = null;
    try {
        boolean isLock = tryLock(lockKey, current_thread_id, 10);
        // 4.2 判斷否獲取成功
        if(!isLock){
            //4.3 失敗，則休眠重試
            Thread.sleep(50);
            return queryWithMutex(id);
        }
        //4.4 成功，根據(jù)id查詢數(shù)據(jù)庫
         shop = getById(id);
        // 5.不存在，返回錯(cuò)誤
        if(shop == null){
             //將空值寫入redis
            stringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
            //返回錯(cuò)誤信息
            return null;
        }
        //6.寫入redis
        stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_NULL_TTL,TimeUnit.MINUTES);
    }catch (Exception e){
        throw new RuntimeException(e);
    }
    finally {
        //7.釋放互斥鎖
        Object o = stringRedisTemplate.opsForValue().get(key);
        if(o != null && (String)o.equals(current_thread_id)){
            unlock(lockKey);
        }
    }
    return shop;
}

利用邏輯過期解決緩存擊穿問題

緩存穿透

緩存穿透 ：緩存穿透是指客戶端請(qǐng)求的數(shù)據(jù)在緩存中和數(shù)據(jù)庫中都不存在，這樣緩存永遠(yuǎn)不會(huì)生效，這些請(qǐng)求都會(huì)打到數(shù)據(jù)庫。

常見的解決方案有以下幾種：

• 緩存空對(duì)象
  • 優(yōu)點(diǎn)：實(shí)現(xiàn)簡單，維護(hù)方便
  • 缺點(diǎn)：
    • 額外的內(nèi)存消耗
    • 可能造成短期的不一致
• 布隆過濾
  • 優(yōu)點(diǎn)：內(nèi)存占用較少，沒有多余key
  • 缺點(diǎn)：
    • 實(shí)現(xiàn)復(fù)雜
    • 存在誤判可能
• id 格式校驗(yàn)

緩存空對(duì)象

思路分析：

當(dāng)我們客戶端訪問不存在的數(shù)據(jù)時(shí)，先請(qǐng)求redis，但是此時(shí)redis中沒有數(shù)據(jù)，此時(shí)會(huì)訪問到數(shù)據(jù)庫，但是數(shù)據(jù)庫中也沒有數(shù)據(jù)，這個(gè)數(shù)據(jù)穿透了緩存，直擊數(shù)據(jù)庫。因?yàn)閿?shù)據(jù)庫能夠承載的并發(fā)不如 redis 這么高，如果大量的請(qǐng)求同時(shí)過來訪問這種不存在的數(shù)據(jù)，這些請(qǐng)求就都會(huì)訪問到數(shù)據(jù)庫，簡單的解決方案就是哪怕這個(gè)數(shù)據(jù)在數(shù)據(jù)庫中也不存在，我們也把這個(gè)數(shù)據(jù)存入到 redis 中去，這樣，下次用戶過來訪問這個(gè)不存在的數(shù)據(jù)，那么在redis中也能找到這個(gè)數(shù)據(jù)就不會(huì)進(jìn)入到緩存了。

布隆過濾

我們可以將數(shù)據(jù)庫的數(shù)據(jù)，所對(duì)應(yīng)的id寫入到一個(gè)list集合中，當(dāng)用戶過來訪問的時(shí)候，我們直接去判斷l(xiāng)ist中是否包含當(dāng)前的要查詢的數(shù)據(jù)，如果說用戶要查詢的id數(shù)據(jù)并不在list集合中，則直接返回，如果list中包含對(duì)應(yīng)查詢的id數(shù)據(jù)，則說明不是一次緩存穿透數(shù)據(jù)，則直接放行。

現(xiàn)在的問題是這個(gè)主鍵其實(shí)并沒有那么短，而是很長的一個(gè) 主鍵哪怕你單獨(dú)去提取這個(gè)主鍵，但是在11年左右，淘寶的商品總量就已經(jīng)超過10億個(gè)所以如果采用以上方案，這個(gè)list也會(huì)很大，所以我們可以使用bitmap來減少list的存儲(chǔ)空間我們可以把list數(shù)據(jù)抽象成一個(gè)非常大的bitmap，我們不再使用list，而是將db中的id數(shù)據(jù)利用哈希思想，比如：id % bitmap.size = 算出當(dāng)前這個(gè)id對(duì)應(yīng)應(yīng)該落在bitmap的哪個(gè)索引上，然后將這個(gè)值從0變成1，然后當(dāng)用戶來查詢數(shù)據(jù)時(shí)，此時(shí)已經(jīng)沒有了list，讓用戶用他查詢的id去用相同的哈希算法， 算出來當(dāng)前這個(gè)id應(yīng)當(dāng)落在bitmap的哪一位，然后判斷這一位是0，還是1，如果是0則表明這一位上的數(shù)據(jù)一定不存在， 采用這種方式來處理，需要重點(diǎn)考慮一個(gè)事情，就是誤差率，所謂的誤差率就是指當(dāng)發(fā)生哈希沖突的時(shí)候，產(chǎn)生的誤差。

id 格式校驗(yàn)

將客戶端傳來的 id 做校驗(yàn)比如：

if(id < 1 || id > Integer.MIN_VALUE){
	return null;
}

具體校驗(yàn)根據(jù)業(yè)務(wù)來。

緩存雪崩

緩存雪崩是指在同一時(shí)段大量的緩存key同時(shí)失效或者Redis服務(wù)宕機(jī)，導(dǎo)致大量請(qǐng)求到達(dá)數(shù)據(jù)庫，帶來巨大壓力。

解決方案

• 給不同的Key的TTL添加隨機(jī)值
• 利用Redis集群提高服務(wù)的可用性
• 給緩存業(yè)務(wù)添加降級(jí)限流策略
• 給業(yè)務(wù)添加多級(jí)緩存

以上就是Redis解決緩存雪崩、穿透和擊穿的問題(Redis使用必看)的詳細(xì)內(nèi)容，更多關(guān)于Redis解決緩存雪崩、穿透和擊穿的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！