Redis+Caffeine 太強了！
兄弟們，咱先聊個扎心的事兒 —— 你是不是也遇到過這樣的情況：線上接口明明加了 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 就會把 “熱門商品” 留在緩存里，把 “小眾商品” 淘汰掉，這樣既能保證常用數據的訪問速度，又不會讓緩存占滿應用的內存。
對比一下之前的 “老古董” 本地緩存比如 Guava Cache，Caffeine 的性能直接碾壓 —— 官方測試數據顯示，在高并發場景下，Caffeine 的命中率比 Guava Cache 高 10%-20%，而且內存占用更省。我之前把項目里的 Guava Cache 換成 Caffeine，接口響應時間直接從 8ms 降到了 3ms，內存占用還少了 15%，簡直是 “降維打擊”。
但 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。
