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

Redis常常用於系統中的緩存（MySQL 與 Redis 緩存的同步方案），這樣能夠解決目前IO設備沒法知足互聯網應用海量的讀寫請求的問題。

1、緩存穿透

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

1. 常看法決方案

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

• 驗證攔截：接口層進行校驗，如鑑定用戶權限，對ID之類的字段作基礎的校驗，如id<=0的字段直接攔截；
• 緩存空數據：當數據庫查詢到的數據爲空時，也將這條數據進行緩存，但緩存的有效性設置得要較短，以避免影響正常數據的緩存；

public 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重複請求效率較高的場景而言，能夠選擇緩存空數據的方案。

2、緩存擊穿

緩存擊穿是指當前熱點數據存儲到期時，多個線程同時併發訪問熱點數據。由於緩存剛過時，全部併發請求都會到數據庫中查詢數據。

解決方案

• 將熱點數據設置爲永不過時；
• 加互斥鎖：互斥鎖能夠控制查詢數據庫的線程訪問，但這種方案會致使系統的吞吐量降低，須要根據實際狀況使用。

public 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;      
    }
}

3、緩存雪崩

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

一個簡單的雪崩過程：

• Redis 集羣產生了大面積故障；
• 緩存失敗，此時仍有大量請求去訪問 Redis 緩存服務器；
• 在大量 Redis 請求失敗後，這些請求將會去訪問數據庫；
• 因爲應用的設計依賴於數據庫和 Redis 服務，很快就會形成服務器集羣的雪崩，最終致使整個系統的癱瘓。

解決方案

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

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

【過後】Redis備份和快速預熱：Redis數據備份和恢復、快速緩存預熱。

做者：週二鴨
來源：https://www.cnblogs.com/jojop...