Redis+Caffeine 太強了！

作者：儒猿團隊 2025-09-01 02:00:00

對比一下之前的 “老古董” 本地緩存比如 Guava Cache，Caffeine 的性能直接碾壓 —— 官方測試數據顯示，在高并發場景下，Caffeine 的命中率比 Guava Cache 高 10%-20%，而且內存占用更省。我之前把項目里的 Guava Cache 換成 Caffeine，接口響應時間直接從 8ms 降到了 3ms，內存占用還少了 15%，簡直是 “降維打擊”。

兄弟們，咱先聊個扎心的事兒 —— 你是不是也遇到過這樣的情況：線上接口明明加了 Redis 緩存，可高峰期還是慢得要死？或者本地緩存用得挺爽，一搞分布式部署就各種數據不一致，心態直接崩了？

我前陣子就踩過這坑：負責的商品詳情接口，一開始只懟了 Redis，QPS 低的時候還挺穩，結果大促前壓測，接口響應時間直接從 20ms 飆到 200ms，運維大哥天天追著我問 “是不是緩存沒生效”。后來查了半天發現，不是 Redis 不行，是每次請求都要跨網絡去撈 Redis 的數據，量大了之后，那網絡開銷就跟堵車似的，越積越慢。

直到我把 Redis 和 Caffeine 湊到一塊兒，嘿，你猜怎么著？接口響應直接打回 10ms 以內，大促峰值也穩得一批。今天就跟大家好好嘮嘮，這倆 “緩存神器” 組隊之后，到底有多強，以及咱們怎么在項目里把它們用明白 —— 全程大白話，沒那么多繞人的術語，放心看！

一、先搞懂：Redis 和 Caffeine，各自到底啥本事？

在說 “組隊” 之前，咱得先摸清這倆貨的底細。就跟打游戲組隊一樣，你得知道輔助能加血、輸出能秒人，才能配合好不是？

1. Redis：“遠程倉庫”，能存還能扛，但跑起來費點勁

Redis 這哥們兒，咱 Java 開發者基本都熟，號稱 “內存數據庫”，但咱平時用得最多的還是它的緩存功能。它的優點那是相當突出：

首先是 “能存”—— 不僅能存字符串，還能存哈希、列表、集合這些復雜結構，比如你想緩存用戶的基本信息 + 訂單列表，直接用哈希或者列表就能搞定，不用自己再拆數據。而且它支持持久化，就算 Redis 服務重啟，之前緩存的數據也能找回來，不用怕 “一重啟緩存全沒了，數據庫瞬間被打崩” 的尷尬。

然后是 “能扛”—— 分布式部署的時候，Redis 能搞集群，多臺機器一起分擔壓力，比如你搞個 3 主 3 從的集群，QPS 輕松上 10 萬，應對大部分業務場景都沒問題。而且它是獨立于應用服務的，不管你應用部署多少臺機器，都能共享一份 Redis 緩存，不會出現 “每臺應用都緩存一份，內存浪費還數據不一致” 的情況。

但 Redis 也有個明顯的短板：它是 “遠程緩存”，也就是說你的應用要拿數據，得通過網絡請求去 Redis 服務器撈。這網絡開銷看著不大，比如一次請求就 1-2ms，但架不住請求多啊！比如你接口 QPS 是 1 萬，那光網絡開銷就占了 1-2 萬 ms 的總耗時，要是再遇到網絡波動，延遲直接翻倍，接口響應時間可不就上去了？

舉個實際的例子：我之前做的用戶中心接口，每次查用戶信息都要先調 Redis，在 QPS 5000 的時候，接口響應時間大概是 15ms，其中有 3ms 都是花在網絡傳輸上。后來把 QPS 提到 1 萬，網絡延遲直接漲到 5ms，接口響應也跟著到了 20ms—— 別小看這幾毫秒，在高并發場景下，這就是 “能用” 和 “好用” 的區別。

2. Caffeine：“桌面快捷方式”，秒回但內存有限

再說說 Caffeine，這玩意兒可能有些兄弟用得少，但它在本地緩存里絕對是 “天花板” 級別的存在。啥是本地緩存？簡單說就是把數據存在你應用服務自己的內存里，拿數據的時候不用走網絡，直接從內存里讀，那速度叫一個快 —— 基本上是微秒級別的，比如一次讀取只要 0.1ms，比 Redis 快了至少 10 倍。

Caffeine 的厲害之處，除了快，還有它的 “緩存淘汰算法”——W-TinyLFU 算法。咱不用糾結這個算法的具體原理，用大白話講就是：它能聰明地判斷哪些數據是 “常用的”，哪些是 “冷門的”，當緩存滿了的時候，優先把冷門數據刪掉，保留常用數據。

比如你做電商網站，首頁的 “熱門商品” 每天被訪問幾十萬次，而某些 “小眾商品” 可能幾天才被訪問一次。Caffeine 就會把 “熱門商品” 留在緩存里，把 “小眾商品” 淘汰掉，這樣既能保證常用數據的訪問速度，又不會讓緩存占滿應用的內存。

但 Caffeine 也有個致命缺點：它是 “本地緩存”，只能存在單個應用實例里。比如你把應用部署了 10 臺機器，那每臺機器都會有一份 Caffeine 緩存，這就會出現兩個問題：

一是 “內存浪費”——10 臺機器都緩存同一份數據，相當于重復存了 10 遍，要是數據量大，內存直接扛不住；

二是 “數據不一致”—— 比如你更新了商品價格，只更了其中一臺機器的 Caffeine 緩存，其他 9 臺還是舊數據，用戶訪問不同機器就會看到不同的價格，這鍋你可背不起。

二、為啥要把 Redis 和 Caffeine 湊一起？1+1>2 的秘密

看完上面倆貨的優缺點，你是不是已經想到了：既然 Redis 能分布式共享、持久化，但慢在網絡；Caffeine 快如閃電，但只能本地存、易不一致 —— 那把它們倆結合起來，不就能互補了嗎？

還真就是這么回事！Redis+Caffeine 的組合，本質上是 “雙層緩存架構”：

第一層：本地 Caffeine 緩存，存 “高頻訪問” 的數據（比如首頁熱門商品、用戶會話信息），拿數據的時候先查這里，秒級響應；
第二層：遠程 Redis 緩存，存 “中頻訪問” 或者 “需要分布式共享” 的數據（比如商品詳情、用戶訂單），當 Caffeine 里沒有的時候，再去 Redis 里撈；
最底層：數據庫，只存 “原始數據”，當 Redis 里也沒有的時候，才去數據庫里查，查完之后再把數據往 Redis 和 Caffeine 里存一份，下次就不用再查數據庫了。

這么一套組合拳打下來，好處可就太多了：

1. 速度快：大部分請求都被 Caffeine 攔住了

根據 “二八定律”，80% 的請求都是訪問那 20% 的高頻數據。比如電商網站，80% 的用戶都是在看首頁的熱門商品，只有 20% 的用戶會去看小眾商品或者詳情頁。

要是只用 Redis，那 80% 的請求都要走網絡去撈 Redis 的數據；但加了 Caffeine 之后，80% 的請求直接從本地內存里拿數據，根本不用碰網絡，接口響應速度自然就上去了。

我之前做的商品首頁接口，加 Caffeine 之前，平均響應時間是 18ms，其中 10ms 是網絡開銷；加了 Caffeine 之后，85% 的請求都命中 Caffeine，平均響應時間直接降到了 5ms，用戶體驗直接拉滿。

2. 扛得住：Redis 壓力大減，數據庫更安全

既然 80% 的請求都被 Caffeine 攔住了，那打到 Redis 上的請求就只剩下 20% 了，Redis 的壓力一下子就小了很多。比如之前 Redis 要扛 1 萬 QPS，現在只需要扛 2000 QPS，就算遇到高峰期，也不容易出現 Redis 過載的情況。

而數據庫就更安全了 —— 只有當 Caffeine 和 Redis 里都沒有數據的時候，才會去查數據庫，這種情況可能只占 1% 都不到。比如我之前做的訂單查詢接口，沒加雙層緩存的時候，數據庫 QPS 高峰期能到 1000，加了之后直接降到 50，數據庫再也沒出現過 “連接超時” 的情況。

3. 數據穩：Redis 保證分布式一致性

雖然 Caffeine 是本地緩存，但我們可以通過 Redis 來保證分布式場景下的數據一致性。比如你更新了商品價格，流程可以是這樣：

先更新數據庫里的商品價格；
然后刪除 Redis 里對應的商品緩存（注意是刪除，不是更新，避免并發問題）；
最后刪除當前應用實例的 Caffeine 緩存。

這樣一來，下次有請求來的時候：

先查 Caffeine，發現沒有，去查 Redis；
Redis 里也沒有，去查數據庫，拿到最新的價格；
把最新價格存到 Redis 和 Caffeine 里，后續的請求就能拿到正確的數據了。

就算你部署了 10 臺機器，只要每臺機器在更新數據的時候，都刪除自己的 Caffeine 緩存和 Redis 緩存，那所有機器后續都會從數據庫里撈最新數據，不會出現數據不一致的情況。

三、實戰：Spring Boot 項目里怎么集成 Redis+Caffeine？

光說不練假把式，接下來咱就手把手教大家，怎么在 Spring Boot 項目里把 Redis 和 Caffeine 集成起來，實現雙層緩存。

1. 先搞依賴：把需要的 Jar 包引進來

首先，在 pom.xml 里加三個依賴：Spring Boot 的緩存 starter、Redis starter、Caffeine 的依賴。注意版本別太老，我這里用的是 Spring Boot 2.7.x 的版本，大家可以根據自己的項目版本調整。

<!-- Spring Boot緩存核心依賴 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<!-- Redis依賴 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- Caffeine依賴 -->
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.1</version> <!-- 這個版本比較穩定，大家可以用最新的 -->
</dependency>
<!-- Redis連接池依賴，提升Redis性能 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
</dependency>

2. 配置文件：告訴項目 Redis 和 Caffeine 在哪

然后在 application.yml 里加配置，主要是 Redis 的連接信息和 Caffeine 的緩存配置。

spring:
  # Redis配置
  redis:
    host: 127.0.0.1 # 你的Redis地址，線上環境要填實際的IP
    port: 6379 # Redis端口，默認6379
    password: 123456 # 你的Redis密碼，沒設的話可以去掉
    lettuce:
      pool:
        max-active: 8 # 最大連接數
        max-idle: 8 # 最大空閑連接數
        min-idle: 2 # 最小空閑連接數
        max-wait: 1000ms # 最大等待時間，超過這個時間就報錯
  # 緩存配置
  cache:
    type: CAFFEINE # 默認緩存類型是Caffeine，后面我們會自定義雙層緩存
    caffeine:
      # Caffeine的緩存配置：初始容量100，最大容量1000，過期時間5分鐘
      initial-capacity: 100
      maximum-size: 1000
      expire-after-write: 5m

這里要注意：Caffeine 的配置要根據你的業務場景來調。比如 “初始容量” 可以設成你預估的常用數據量，避免頻繁擴容；“最大容量” 不能設太大，不然會占滿應用內存，比如你應用內存是 2G，那 Caffeine 最大容量別超過 5000（具體看每條數據的大小）；“過期時間” 要看數據的更新頻率，比如商品價格一天更一次，那過期時間可以設 1 天，要是實時性要求高，比如用戶余額，那過期時間可以設 5 分鐘。

3. 核心配置類：實現雙層緩存邏輯

這一步是關鍵 —— 我們要自定義一個緩存管理器，讓它同時支持 Caffeine 和 Redis，實現 “先查 Caffeine，再查 Redis，最后查數據庫” 的邏輯。

首先，寫一個 Redis 的配置類，主要是配置 RedisTemplate，避免默認的序列化問題（默認的 JdkSerializationRedisSerializer 會把數據序列化成亂碼）：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;
@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(LettuceConnectionFactory lettuceConnectionFactory) {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        // 配置連接工廠
        redisTemplate.setConnectionFactory(lettuceConnectionFactory);
        // 配置Key的序列化器：用StringRedisSerializer，避免Key出現亂碼
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
        redisTemplate.setKeySerializer(stringRedisSerializer);
        redisTemplate.setHashKeySerializer(stringRedisSerializer);
        // 配置Value的序列化器：用GenericJackson2JsonRedisSerializer，把對象轉成JSON
        GenericJackson2JsonRedisSerializer jsonRedisSerializer = new GenericJackson2JsonRedisSerializer();
        redisTemplate.setValueSerializer(jsonRedisSerializer);
        redisTemplate.setHashValueSerializer(jsonRedisSerializer);
        // 初始化RedisTemplate
        redisTemplate.afterPropertiesSet();
        return redisTemplate;
    }
}

然后，寫一個雙層緩存的配置類，自定義緩存管理器：

import com.github.ben-manes.caffeine.cache.Caffeine;
import org.springframework.cache.Cache;
import org.springframework.cache.CacheManager;
import org.springframework.cache.caffeine.CaffeineCache;
import org.springframework.cache.support.CompositeCacheManager;
import org.springframework.cache.support.SimpleCacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCache;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.core.RedisTemplate;
import java.time.Duration;
import java.util.ArrayList;
import java.util.List;
@Configuration
public class CacheConfig {
    // 1. 配置Caffeine緩存管理器
    @Bean
    public CacheManager caffeineCacheManager() {
        SimpleCacheManager cacheManager = new SimpleCacheManager();
        List<Cache> caches = new ArrayList<>();
        // 這里可以配置多個Caffeine緩存，比如針對不同業務場景設置不同的過期時間
        // 示例1：商品熱門緩存，過期時間5分鐘
        caches.add(new CaffeineCache("hotProductCache", 
                Caffeine.newBuilder()
                        .initialCapacity(100)
                        .maximumSize(1000)
                        .expireAfterWrite(Duration.ofMinutes(5))
                        .build()));
        // 示例2：用戶會話緩存，過期時間30分鐘
        caches.add(new CaffeineCache("userSessionCache", 
                Caffeine.newBuilder()
                        .initialCapacity(50)
                        .maximumSize(500)
                        .expireAfterWrite(Duration.ofMinutes(30))
                        .build()));
        cacheManager.setCaches(caches);
        return cacheManager;
    }
    // 2. 配置Redis緩存管理器
    @Bean
    public CacheManager redisCacheManager(RedisTemplate<String, Object> redisTemplate) {
        // Redis緩存配置：過期時間1小時，Key前綴加"cache:"
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofHours(1)) // 過期時間1小時
                .prefixCacheNameWith("cache:") // Key前綴，比如"hotProductCache:123"
                .serializeKeysWith(RedisCacheConfiguration.defaultCacheConfig().getKeySerializationPair())
                .serializeValuesWith(RedisCacheConfiguration.defaultCacheConfig().getValueSerializationPair());
        // 創建Redis緩存管理器
        return RedisCacheManager.builder(redisTemplate.getConnectionFactory())
                .cacheDefaults(config)
                .build();
    }
    // 3. 配置復合緩存管理器：先查Caffeine，再查Redis
    @Bean
    public CacheManager compositeCacheManager(CacheManager caffeineCacheManager, CacheManager redisCacheManager) {
        CompositeCacheManager compositeCacheManager = new CompositeCacheManager(caffeineCacheManager, redisCacheManager);
        // 設置為"true"表示：如果前面的緩存（Caffeine）沒命中，就繼續查后面的緩存（Redis）
        compositeCacheManager.setFallbackToNoOpCache(false);
        return compositeCacheManager;
    }
}

這里解釋一下：CompositeCacheManager 是 Spring 提供的復合緩存管理器，它會按照你傳入的緩存管理器順序去查詢 —— 先查 caffeineCacheManager，要是沒命中，再查 redisCacheManager。這樣就實現了 “先本地，再遠程” 的雙層緩存邏輯。而且我們可以針對不同的業務場景，配置不同的緩存（比如 hotProductCache、userSessionCache），每個緩存的初始容量、最大容量、過期時間都可以單獨設置，非常靈活。

4. 業務代碼：用 @Cacheable 注解實現緩存

配置完之后，業務代碼就簡單了 —— 只需要在需要緩存的方法上加 @Cacheable 注解，指定用哪個緩存就行。

比如我們寫一個商品服務，查詢熱門商品的方法：

import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
@Service
public class ProductService {
    // 模擬從數據庫查詢商品信息
    private Product getProductFromDb(Long productId) {
        // 這里實際項目中會調用DAO層查數據庫，這里模擬一下
        System.out.println("從數據庫查詢商品：" + productId);
        return new Product(productId, "iPhone 15", 5999.0);
    }
    /**
     * 查詢熱門商品信息
     * @Cacheable：表示這個方法的返回值會被緩存
     * value：指定用哪個緩存（對應我們之前配置的"hotProductCache"）
     * key：緩存的Key，這里用商品ID作為Key，比如"hotProductCache:1"
     */
    @Cacheable(value = "hotProductCache", key = "#productId")
    public Product getHotProduct(Long productId) {
        // 要是緩存沒命中，就會執行下面的代碼（查數據庫）
        return getProductFromDb(productId);
    }
}

再寫一個 Controller，調用這個服務：

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
@RestController
public class ProductController {
    @Resource
    private ProductService productService;
    @GetMapping("/product/hot/{productId}")
    public Product getHotProduct(@PathVariable Long productId) {
        long start = System.currentTimeMillis();
        Product product = productService.getHotProduct(productId);
        long end = System.currentTimeMillis();
        System.out.println("接口響應時間：" + (end - start) + "ms");
        return product;
    }
}

然后我們測試一下：

第一次訪問http://localhost:8080/product/hot/1，控制臺會打印 “從數據庫查詢商品：1” 和 “接口響應時間：20ms”（因為要查數據庫）；
第二次訪問同一個地址，控制臺只會打印 “接口響應時間：1ms”（因為命中了 Caffeine 緩存，不用查數據庫和 Redis）；
要是我們把應用重啟，第一次訪問會打印 “從數據庫查詢商品：1” 嗎？不會！因為重啟后 Caffeine 緩存沒了，但 Redis 緩存還在，所以會先查 Caffeine（沒命中），再查 Redis（命中），控制臺會打印 “接口響應時間：5ms”，不用查數據庫。

你看，這樣就完美實現了雙層緩存的效果 —— 第一次查數據庫，之后查 Caffeine，重啟后查 Redis，全程不用頻繁碰數據庫，速度又快又穩。

四、進階：解決 Redis+Caffeine 的那些 “坑”

雖然 Redis+Caffeine 很好用，但實際項目中還是會遇到一些問題，比如緩存穿透、緩存雪崩、數據不一致這些，要是不解決，分分鐘出線上事故。接下來咱就聊聊這些 “坑” 怎么填。

1. 緩存穿透：請求查 “不存在的數據”，怎么辦？

啥是緩存穿透？就是有人故意請求一個不存在的數據，比如查 productId=9999 的商品（數據庫里根本沒有），這樣每次請求都會穿透 Caffeine 和 Redis，直接打到數據庫上，要是請求多了，數據庫直接就崩了。

怎么解決？有兩個辦法：

（1）緩存 “空值”

當數據庫里沒有這個數據的時候，我們也把 “空值” 存到 Caffeine 和 Redis 里，比如存一個 null 或者一個空對象，這樣下次再查這個數據的時候，就會命中緩存，不會再查數據庫了。

修改一下 ProductService 里的 getHotProduct 方法：

@Cacheable(value = "hotProductCache", key = "#productId", unless = "#result == null")
public Product getHotProduct(Long productId) {
    Product product = getProductFromDb(productId);
    // 要是數據庫里沒有這個商品，返回一個空對象（不是null）
    if (product == null) {
        return new Product(productId, "", 0.0);
    }
    return product;
}

這里的 unless = "#result == null" 表示：如果返回值是 null，就不緩存。所以我們返回一個空對象，這樣就能把空對象緩存起來，下次再查的時候，就會命中緩存。

（2）布隆過濾器：提前攔截 “不存在的數據”

要是請求的 “不存在的數據” 太多，緩存空值會浪費 Redis 和 Caffeine 的內存，這時候就可以用布隆過濾器。布隆過濾器就像一個 “黑名單”，里面存了所有存在的 productId，當有請求來的時候，先過布隆過濾器：

要是布隆過濾器說 “這個 productId 不存在”，直接返回 404，不用查緩存和數據庫；
要是布隆過濾器說 “這個 productId 存在”，再走緩存和數據庫的流程。

Spring Boot 里集成布隆過濾器也很簡單，用 Redisson 的布隆過濾器就行：

首先加 Redisson 依賴：

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.17.6</version>
</dependency>

然后寫一個布隆過濾器的配置類：

import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
publicclass BloomFilterConfig {

    // 布隆過濾器的預期元素數量（比如有10000個商品）
    privatestaticfinallong EXPECTED_INSERTIONS = 10000;
    // 布隆過濾器的誤判率（越小越準，但占用內存越大，一般設0.01）
    privatestaticfinaldouble FALSE_POSITIVE_RATE = 0.01;

    @Bean
    public RBloomFilter<Long> productBloomFilter(RedissonClient redissonClient) {
        // 獲取布隆過濾器（名字叫"productBloomFilter"）
        RBloomFilter<Long> bloomFilter = redissonClient.getBloomFilter("productBloomFilter");
        // 初始化布隆過濾器
        bloomFilter.tryInit(EXPECTED_INSERTIONS, FALSE_POSITIVE_RATE);

        // 這里要把數據庫里所有的productId加到布隆過濾器里（實際項目中可以在項目啟動時加載）
        // 模擬添加10000個商品ID
        for (long i = 1; i <= 10000; i++) {
            bloomFilter.add(i);
        }

        return bloomFilter;
    }
}

然后修改 Controller 里的方法，先過布隆過濾器：

@GetMapping("/product/hot/{productId}")
public Product getHotProduct(@PathVariable Long productId) {
    // 先查布隆過濾器，要是不存在，直接返回404
    if (!productBloomFilter.contains(productId)) {
        throw new RuntimeException("商品不存在");
    }

    long start = System.currentTimeMillis();
    Product product = productService.getHotProduct(productId);
    long end = System.currentTimeMillis();
    System.out.println("接口響應時間：" + (end - start) + "ms");
    return product;
}

這樣一來，要是有人查 productId=10001 的商品，布隆過濾器直接攔截，不會再走緩存和數據庫，完美解決緩存穿透問題。

2. 緩存雪崩：大量緩存同時過期，怎么辦？

啥是緩存雪崩？就是你設置的緩存都在同一個時間點過期，比如你把所有商品緩存的過期時間都設成 1 小時，那 1 小時后，所有緩存都會過期，這時候大量請求會一下子全打到數據庫上，數據庫直接扛不住。

怎么解決？有兩個辦法：

（1）給過期時間加 “隨機值”

不要讓所有緩存都在同一個時間過期，比如在基礎過期時間上再加一個 0-300 秒的隨機值，這樣緩存過期時間就分散了，不會出現 “同時過期” 的情況。

修改 CacheConfig 里的 Caffeine 緩存配置：

// 示例1：商品熱門緩存，過期時間5分鐘+隨機0-300秒
caches.add(new CaffeineCache("hotProductCache", 
        Caffeine.newBuilder()
                .initialCapacity(100)
                .maximumSize(1000)
                .expireAfterWrite(Duration.ofMinutes(5).plus(Duration.ofSeconds((long) (Math.random() * 300))))
                .build()));

Redis 的過期時間也一樣，修改 RedisCacheConfiguration：

RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
        // 過期時間1小時+隨機0-300秒
        .entryTtl(Duration.ofHours(1).plus(Duration.ofSeconds((long) (Math.random() * 300))))
        .prefixCacheNameWith("cache:")
        .serializeKeysWith(RedisCacheConfiguration.defaultCacheConfig().getKeySerializationPair())
        .serializeValuesWith(RedisCacheConfiguration.defaultCacheConfig().getValueSerializationPair());

這樣一來，每個緩存的過期時間都不一樣，就不會出現大量緩存同時過期的情況了。

（2）Redis 集群：避免 Redis 單點故障

要是 Redis 服務器掛了，那所有依賴 Redis 的請求都會打到數據庫上，也會造成 “雪崩”。所以線上環境一定要搞 Redis 集群，比如 3 主 3 從，就算其中一臺主節點掛了，從節點會自動頂上，保證 Redis 服務不中斷。

3. 數據不一致：更新數據后，緩存沒同步，怎么辦？

這個問題我們之前提過一嘴，就是更新數據庫后，要及時刪除對應的緩存，避免緩存里存的是舊數據。但實際項目中，可能會遇到 “并發更新” 的問題，比如：

線程 A 查詢商品 1，緩存沒命中，去查數據庫，拿到舊價格 5999；
線程 B 更新商品 1 的價格，改成 6999，然后刪除了緩存；
線程 A 查完數據庫，把舊價格 5999 又存到緩存里；
之后的請求查緩存，拿到的都是舊價格 5999，出現數據不一致。

怎么解決？有兩個辦法：

（1）“更新數據庫→刪除緩存” 改成 “刪除緩存→更新數據庫”

先刪除緩存，再更新數據庫，這樣就算有線程在更新前查詢，也會因為緩存被刪除，去查數據庫，拿到的是最新的數據。

修改一下更新商品的方法：

import org.springframework.cache.annotation.CacheEvict;
import org.springframework.stereotype.Service;

@Service
publicclass ProductService {

    // 模擬更新數據庫里的商品信息
    private void updateProductInDb(Product product) {
        System.out.println("更新數據庫商品：" + product.getId() + "，新價格：" + product.getPrice());
    }

    /**
     * 更新商品信息
     * @CacheEvict：表示更新后刪除對應的緩存
     * value：要刪除的緩存名稱
     * key：要刪除的緩存Key
     */
    @CacheEvict(value = "hotProductCache", key = "#product.id")
    public void updateProduct(Product product) {
        // 1. 先刪除緩存
        // （@CacheEvict注解會幫我們做這件事）

        // 2. 再更新數據庫
        updateProductInDb(product);

        // 3. 再刪除Redis里的緩存（因為@CacheEvict默認只刪除Caffeine緩存）
        redisTemplate.delete("cache:hotProductCache:" + product.getId());
    }
}

這里要注意：@CacheEvict 注解默認只會刪除 Caffeine 緩存，所以我們還要手動刪除 Redis 里的緩存，保證兩者都被刪除。

（2）加互斥鎖：避免并發更新導致的問題

要是并發量特別大，就算先刪除緩存再更新數據庫，還是可能出現問題，這時候就可以加互斥鎖，比如用 Redis 的 SETNX 命令（只有當 Key 不存在的時候才能設置成功），保證同一時間只有一個線程能更新商品。

修改 updateProduct 方法：

public void updateProduct(Product product) {
    String lockKey = "lock:product:" + product.getId();
    // 加互斥鎖，過期時間5秒，避免死鎖
    Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(5));
    if (Boolean.TRUE.equals(locked)) {
        try {
            // 1. 刪除Caffeine緩存
            caffeineCacheManager.getCache("hotProductCache").evict(product.getId());

            // 2. 刪除Redis緩存
            redisTemplate.delete("cache:hotProductCache:" + product.getId());

            // 3. 更新數據庫
            updateProductInDb(product);
        } finally {
            // 釋放鎖
            redisTemplate.delete(lockKey);
        }
    } else {
        // 沒拿到鎖，重試（可以用循環重試，或者返回失敗讓前端重試）
        thrownew RuntimeException("更新太頻繁，請稍后再試");
    }
}

這樣一來，同一時間只有一個線程能更新商品，就不會出現 “線程 A 存舊數據” 的問題了。

五、總結：Redis+Caffeine，該用在哪些場景？

聊了這么多，最后咱總結一下，Redis+Caffeine 的雙層緩存架構，到底適合哪些場景：

高并發、低延遲要求的場景：比如電商首頁、秒殺活動、直播帶貨，這些場景 QPS 高，用戶對響應時間敏感，用雙層緩存能把響應時間壓到 10ms 以內；
數據訪問頻率差異大的場景：比如大部分請求訪問高頻數據，少部分請求訪問低頻數據，用 Caffeine 存高頻數據，Redis 存低頻數據，既能保證速度，又能節省內存；
分布式部署的場景：比如應用部署多臺機器，需要共享緩存數據，用 Redis 保證分布式一致性，用 Caffeine 提升單機訪問速度。

當然，也不是所有場景都適合用雙層緩存。比如數據實時性要求極高的場景（比如股票行情、實時訂單數），緩存過期時間要設得很短，甚至不用緩存，直接查數據庫；或者數據訪問頻率很低的場景（比如后臺管理系統），用單 Redis 緩存就夠了，沒必要加 Caffeine。

責任編輯：武曉燕來源：石杉的架構筆記