快取過程存在的三大問題及解決方案

Redis 經常用於系統中的快取，可以極大地提高了系統效能和效率，但同時也帶來一些問題。一個是資料一致性問題。從嚴格意義上講，只要使用快取，就會出現一致性問題，這是無法解決的。另一個問題是本文將討論的快取穿透，快取擊穿和快取雪崩，這三個問題不僅限於 Redis，其他快取工具同樣需要面對這三個問題。接下來我詳細講解這三個問題以及對應的解決方案。

一、快取穿透

---

快取穿透意味著當使用者查詢資料庫不存在資料時，返回的結果為空，並且結果不會在快取中儲存。假設使用者不斷髮起這樣的請求，它將永遠不會訪問快取，導致所有查詢都落在資料庫上，從而導致資料庫被打死。

public Object getGoods(Long goodsId) {
    //從 Redis 獲取 goods 資訊
    Object goodsInfo = redisTemplate.opsForValue()
                .get(String.valueOf(goodsId));
        if (goodsInfo != null) {
            return goodsInfo;
        }
    //從資料庫查詢 goods 資訊，並存入 Redis
    goodsInfo = goodsDao.selectByGoodsId(goodsId);
        if (goodsInfo != null) {
        redisTemplate.opsForValue()
                .set(String.valueOf(goodsId), goodsInfo);
        }
    return goodsInfo;
}

假設 goodsId 沒有負數情況，如果發起一個引數 goodsId = -1 的請求，這個資料在快取中肯定不會存在，每次它都會進入查詢資料庫，並且資料查詢結果也是 null，並且不會快取結果到 Redis。

解：

1） 透過使用者認證、引數驗證等，在上層攔截這些不合理的請求；

2） 當資料庫查詢結果為空時，資料也被快取，但快取有效期設定較短，以免影響正常資料的快取。

public Object getGoods(Long goodsId) {
    //從 Redis 獲取 goods 資訊
    Object goodsInfo = redisTemplate.opsForValue()
            .get(String.valueOf(goodsId));
    if (goodsInfo != null) {
        return goodsInfo;
    }

    //從資料庫查詢 goods 資訊，並存入 Redis
    goodsInfo = goodsDao.selectByGoodsId(goodsId);
         if (goodsInfo != null) {
            redisTemplate.opsForValue()
                .set(String.valueOf(goodsId), goodsInfo
                    , 60, TimeUnit.MINUTES);
         } else { //查詢為 null 同樣儲存
            redisTemplate.opsForValue()
                .set(String.valueOf(goodsId), null, 60,
                    TimeUnit.SECONDS);
    }
    return goodsInfo;
}

二、快取擊穿

---

快取擊穿意味著當熱點資料儲存到期時，多個執行緒同時請求熱點資料。因為快取剛過期，所有併發請求都會到資料庫查詢資料。

解：
實際上，在大多數實際業務場景中，快取擊穿是實時發生的，但不會對資料庫造成太大壓力，因為一般的公司業務，併發量不會那麼高。當然如果你不幸有這種情況，你可以透過設定這些熱點鍵，使其永遠不會過期。另一種方法是透過互斥鎖來控制查詢資料庫的執行緒訪問，但這種會導致系統的吞吐率下降，需要實際情況使用。

三、快取雪崩

---

資料未載入到快取中，或者快取同時在大範圍中失效，導致所有請求查詢資料庫，導致資料庫、CPU 和記憶體過載，甚至停機。
一個簡單的雪崩過程：
1） Redis 叢集的大面積故障；
2） 快取失敗，但仍有大量請求訪問快取服務 Redis；
3） 在大量 Redis 請求失敗後，請求轉向資料庫；
4） 資料庫請求急劇增加，導致資料庫被打死；
5） 由於你應用程式服務大部分都依賴於資料庫和 Redis 服務，它很快就會導致伺服器叢集的雪崩，最後整個系統將徹底崩潰。
解：
事前：高可用的快取
高可用的快取是防止出現整個快取故障。即使個別節點，機器甚甚至機房都關閉，系統仍然可以提供服務，Redis 哨兵(Sentinel) 和 Redis 叢集(Cluster) 都可以做到高可用。
事中：快取降級（臨時支援）
當訪問次數急劇增加導致服務出現問題時，我們如何確保服務仍然可用。在國內使用比較多的是 Hystrix，它透過熔斷、降級、限流三個手段來降低雪崩發生後的損失。只要確保資料庫不死，系統總可以響應請求，每年的春節 12306 我們不都是這麼過來的嗎？只要還可以響應起碼還有搶到票的機會。
事後：Redis 備份和快速預熱
1） Redis 資料備份和恢復
2） 快速快取預熱

四、小結

---

目前的大部分的系統都增加了快取機制，避免對資料庫造成過大壓力導致系統出問題，極大的提升系統穩定性。雖然使用快取能夠給系統帶來了一定的質的提升，但同時也帶來快取穿透、快取擊穿、快取雪崩問題等問題。特別是當併發量增大、惡意攻擊的時候，是很難避免。這些問題應該在設計系統時候就應該考慮，這樣設計出來的系統才經得起考驗。

想了解更多關於資料庫、雲技術的內容嗎？

快來關注“資料和雲"、"雲和恩墨，"公眾號及"雲和恩墨"官方網站，我們期待大家一同學習與進步！

資料和雲小程式”DBASK“線上問答，隨時解惑，歡迎瞭解和關注！