Redis緩存中有哪些問題

這篇文章給大家分享的是有關Redis緩存中有哪些問題的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

一、緩存穿透

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

1. 常見解決方案

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

• 驗證攔截：接口層進行校驗，如鑒定用戶權限，對 ID 之類的字段做基礎的校驗，如 id<=0 的字段直接攔截；

• 緩存空數據：當數據庫查詢到的數據為空時，也將這條數據進行緩存，但緩存的有效性設置得要較短，以免影響正常數據的緩存；

Copypublic Student getStudentsByID(Long id) {

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

// 從數據庫查詢學生信息，并存入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;

}

使用布隆過濾器：布隆過濾器是一種比較獨特數據結構，有一定的誤差。當它指定一個數據存在時，它不一定存在，但是當它指定一個數據不存在時，那么它一定是不存在的。

2. 布隆過濾器

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

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

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

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

3. 緩存空數據與布隆過濾器的比較

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

• 當一些惡意攻擊查詢查詢的 key 各不相同，而且數量巨多，此時緩存空數據不是一個好的解決方案。因為它需要存儲所有的 Key，內存空間占用高。并且在這種情況下，很多 key 可能只用一次，所以存儲下來沒有意義。所以對于這種情況而言，使用布隆過濾器是個不錯的選擇；

• 而對與空數據的 Key 數量有限、Key 重復請求效率較高的場景而言，可以選擇緩存空數據的方案。

二、緩存擊穿

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

解決方案

• 將熱點數據設置為永不過期；

• 加互斥鎖：互斥鎖可以控制查詢數據庫的線程訪問，但這種方案會導致系統的吞吐量下降，需要根據實際情況使用。

Copypublic String get(key) 
{
    String value = redis.get(key);
    if (value == null) 
    {
        // 代表緩存值過期 // 設置3min的超時，防止del操作失敗的時候，下次緩存過期一直不能
        load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {
            // 代表設置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        }
        else {
            // 這個時候代表同時候的其他線程已經load db并回設到緩存了，這時候重試獲取緩存值即可
            sleep(50);
            get(key);
            // 重試
        }
    }
    else {
        return value;
    }
}

三、緩存雪崩

緩存雪崩發生有幾種情況，比如大量緩存集中在或者緩存同時在大范圍中失效，出現了大量請求去訪問數據庫，從而導致 CPU 和內存過載，甚至停機。

一個簡單的雪崩過程：

1. Redis 集群產生了大面積故障；

2. 緩存失敗，此時仍有大量請求去訪問 Redis 緩存服務器；

3. 在大量 Redis 請求失敗后，這些請求將會去訪問數據庫；

4. 由于應用的設計依賴于數據庫和 Redis 服務，很快就會造成服務器集群的雪崩，最終導致整個系統的癱瘓。

解決方案

• 【事前】高可用緩存：高可用緩存是防止出現整個緩存故障。即使個別節點，機器甚至機房都關閉，系統仍然可以提供服務，Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都可以做到高可用；

• 【事中】緩存降級（臨時支持）：當訪問次數急劇增加導致服務出現問題時，我們如何確保服務仍然可用。在國內使用比較多的是 Hystrix，它通過熔斷、降級、限流三個手段來降低雪崩發生后的損失。只要確保數據庫不死，系統總可以響應請求，每年的春節 12306 我們不都是這么過來的嗎？只要還可以響應起碼還有搶到票的機會；

• 【事后】Redis 備份和快速預熱：Redis 數據備份和恢復、快速緩存預熱。

感謝各位的閱讀！關于“Redis緩存中有哪些問題”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！