淺談Redis 緩存的三大問題及其解決方案

Posted on by

Redis 經常用於系統中的緩存，這樣可以解決目前 IO 設備無法滿足互聯網應用海量的讀寫請求的問題。

一、緩存穿透

緩存穿透是指緩存和數據庫中都沒有的數據，而用戶不斷發起請求，如發起 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 緩存的三大問題及其解決方案的文章就介紹到這瞭,更多相關Redis 緩存問題內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：