Redis 經(jīng)常用于系統(tǒng)中的緩存，這樣可以解決目前 IO 設(shè)備無法滿足互聯(lián)網(wǎng)應(yīng)用海量的讀寫請求的問題。

一、緩存穿透

緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù)，而用戶不斷發(fā)起請求，如發(fā)起 id 為-1 的數(shù)據(jù)或者特別大的不存在的數(shù)據(jù)。有可能是黑客利用漏洞攻擊從而去壓垮應(yīng)用的數(shù)據(jù)庫。

1. 常見解決方案

對于緩存穿透問題，常見的解決方案有以下三種：

• 驗證攔截：接口層進(jìn)行校驗，如鑒定用戶權(quán)限，對 ID 之類的字段做基礎(chǔ)的校驗，如 id<=0 的字段直接攔截；
• 緩存空數(shù)據(jù)：當(dāng)數(shù)據(jù)庫查詢到的數(shù)據(jù)為空時，也將這條數(shù)據(jù)進(jìn)行緩存，但緩存的有效性設(shè)置得要較短，以免影響正常數(shù)據(jù)的緩存；

Copypublic Student getStudentsByID(Long id) {

// 從Redis中獲取學(xué)生信息
Student student = redisTemplate.opsForValue()
    .get(String.valueOf(id));
if (student != null) {
    return student;
}

// 從數(shù)據(jù)庫查詢學(xué)生信息，并存入Redis
student = studentDao.selectByStudentId(id);
if (student != null) {
    redisTemplate.opsForValue()
        .set(String.valueOf(id), student, 60, TimeUnit.MINUTES);
} else {
    // 即使不存在，也將其存入緩存中
    redisTemplate.opsForValue()
        .set(String.valueOf(id), null, 60, TimeUnit.SECONDS);
}

return student;

}

使用布隆過濾器：布隆過濾器是一種比較獨特數(shù)據(jù)結(jié)構(gòu)，有一定的誤差。當(dāng)它指定一個數(shù)據(jù)存在時，它不一定存在，但是當(dāng)它指定一個數(shù)據(jù)不存在時，那么它一定是不存在的。

2. 布隆過濾器

布隆過濾器是一種比較特殊的數(shù)據(jù)結(jié)構(gòu)，有點類似與 HashMap，在業(yè)務(wù)中我們可能會通過使用 HashMap 來判斷一個值是否存在，它可以在 O(1)時間復(fù)雜度內(nèi)返回結(jié)果，效率極高，但是受限于存儲容量，如果可能需要去判斷的值超過億級別，那么 HashMap 所占的內(nèi)存就很可觀了。

而 BloomFilter 解決這個問題的方案很簡單。首先用多個 bit 位去代替 HashMap 中的數(shù)組，這樣的話儲存空間就下來了，之后就是對 Key 進(jìn)行多次哈希，將 Key 哈希后的值所對應(yīng)的 bit 位置為 1。

當(dāng)判斷一個元素是否存在時，就去判斷這個值哈希出來的比特位是否都為 1，如果都為 1，那么可能存在，也可能不存在（如下圖 F）。但是如果有一個 bit 位不為 1，那么這個 Key 就肯定不存在。

注意：BloomFilter 并不支持刪除操作，只支持添加操作。這一點很容易理解，因為你如果要刪除數(shù)據(jù)，就得將對應(yīng)的 bit 位置為 0，但是你這個 Key 對應(yīng)的 bit 位可能其他的 Key 也對應(yīng)著。

3. 緩存空數(shù)據(jù)與布隆過濾器的比較

上面對這兩種方案都進(jìn)行了簡單的介紹，緩存空數(shù)據(jù)與布隆過濾器都能有效解決緩存穿透問題，但使用場景有著些許不同；

• 當(dāng)一些惡意攻擊查詢查詢的 key 各不相同，而且數(shù)量巨多，此時緩存空數(shù)據(jù)不是一個好的解決方案。因為它需要存儲所有的 Key，內(nèi)存空間占用高。并且在這種情況下，很多 key 可能只用一次，所以存儲下來沒有意義。所以對于這種情況而言，使用布隆過濾器是個不錯的選擇；
• 而對與空數(shù)據(jù)的 Key 數(shù)量有限、Key 重復(fù)請求效率較高的場景而言，可以選擇緩存空數(shù)據(jù)的方案。

二、緩存擊穿

緩存擊穿是指當(dāng)前熱點數(shù)據(jù)存儲到期時，多個線程同時并發(fā)訪問熱點數(shù)據(jù)。因為緩存剛過期，所有并發(fā)請求都會到數(shù)據(jù)庫中查詢數(shù)據(jù)。

解決方案

• 將熱點數(shù)據(jù)設(shè)置為永不過期；
• 加互斥鎖：互斥鎖可以控制查詢數(shù)據(jù)庫的線程訪問，但這種方案會導(dǎo)致系統(tǒng)的吞吐量下降，需要根據(jù)實際情況使用。

Copypublic String get(key) 
{
    String value = redis.get(key);
    if (value == null) 
    {
        // 代表緩存值過期 // 設(shè)置3min的超時，防止del操作失敗的時候，下次緩存過期一直不能
        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 {
            // 這個時候代表同時候的其他線程已經(jīng)load db并回設(shè)到緩存了，這時候重試獲取緩存值即可
            sleep(50);
            get(key);
            // 重試
        }
    }
    else {
        return value;
    }
}

三、緩存雪崩

緩存雪崩發(fā)生有幾種情況，比如大量緩存集中在或者緩存同時在大范圍中失效，出現(xiàn)了大量請求去訪問數(shù)據(jù)庫，從而導(dǎo)致 CPU 和內(nèi)存過載，甚至停機(jī)。

一個簡單的雪崩過程：

1. Redis 集群產(chǎn)生了大面積故障；
2. 緩存失敗，此時仍有大量請求去訪問 Redis 緩存服務(wù)器；
3. 在大量 Redis 請求失敗后，這些請求將會去訪問數(shù)據(jù)庫；
4. 由于應(yīng)用的設(shè)計依賴于數(shù)據(jù)庫和 Redis 服務(wù)，很快就會造成服務(wù)器集群的雪崩，最終導(dǎo)致整個系統(tǒng)的癱瘓。

解決方案

• 【事前】高可用緩存：高可用緩存是防止出現(xiàn)整個緩存故障。即使個別節(jié)點，機(jī)器甚至機(jī)房都關(guān)閉，系統(tǒng)仍然可以提供服務(wù)，Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都可以做到高可用；
• 【事中】緩存降級（臨時支持）：當(dāng)訪問次數(shù)急劇增加導(dǎo)致服務(wù)出現(xiàn)問題時，我們?nèi)绾未_保服務(wù)仍然可用。在國內(nèi)使用比較多的是 Hystrix，它通過熔斷、降級、限流三個手段來降低雪崩發(fā)生后的損失。只要確保數(shù)據(jù)庫不死，系統(tǒng)總可以響應(yīng)請求，每年的春節(jié) 12306 我們不都是這么過來的嗎？只要還可以響應(yīng)起碼還有搶到票的機(jī)會；
• 【事后】Redis 備份和快速預(yù)熱：Redis 數(shù)據(jù)備份和恢復(fù)、快速緩存預(yù)熱。

到此這篇關(guān)于淺談Redis 緩存的三大問題及其解決方案的文章就介紹到這了,更多相關(guān)Redis 緩存問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論