本地缓存 Caffeine 与 Redis 分布式缓存怎么结合使用

本地缓存 Caffeine 与 Redis 分布式缓存结合使用，通常采用“一级本地缓存 + 二级分布式缓存”的多级架构。这种方案适合高并发读多写少场景，能显著降低网络延迟，但必须处理好多节点间的数据一致性风险。

先说结论：Caffeine 负责进程内热点数据加速，Redis 负责跨节点数据共享，两者协同可平衡性能与一致性。

快速处理思路

在 Spring Boot 项目中，可通过配置 Caffeine 作为本地缓存实现，Redis 作为远程缓存实现，利用 Spring Cache 抽象层统一管理。

spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=10000,expireAfterWrite=60s
  redis:
    host: localhost
    port: 6379

代码层面采用“先查 Caffeine，未命中查 Redis，仍未命中查数据库”的逻辑，更新数据时同步清除两级缓存。

单一 Redis 缓存存在网络 IO 开销和序列化成本，单一本地缓存存在数据不一致和内存限制问题。

Caffeine 基于 JVM 堆内存，访问延迟达到纳秒级，能拦截大部分热点请求；Redis 作为分布式中间件，支持跨服务共享和持久化。两者结合既利用了本地内存的极致速度，又保留了分布式缓存的一致性基础。

第一步：引入依赖并配置多级缓存，在 Spring Boot 配置文件中指定缓存类型为 Caffeine 并连接 Redis。

第二步：实现缓存读取逻辑，优先访问本地缓存，未命中时再查询 Redis 并回写本地。

第三步：实现缓存更新逻辑，确保数据库变更后同步失效 Redis 和 Caffeine，避免脏读。

第四步：部署一致性保障机制，如 Redis Pub/Sub 广播清除消息或设置较短的本地缓存 TTL。

查看应用日志确认缓存命中来源，或通过监控工具观察 Redis 请求量是否下降。

压测场景下，对比开启多级缓存前后的平均响应时间，确认本地缓存是否承担了主要流量。

数据一致性风险：多节点本地缓存可能保留旧数据，需通过消息通知或短 TTL 解决。

内存溢出风险：本地缓存未设置最大容量限制，可能导致 JVM OOM。

缓存雪崩风险：热点数据同时失效，大量请求穿透到数据库。

Redis 存在网络延迟和序列化开销，高并发热点场景下可能成为瓶颈，本地缓存可进一步降低延迟。

可通过 Redis Pub/Sub 发布失效消息通知所有节点清除本地缓存，或设置较短的本地缓存过期时间。

Caffeine 基于 W-TinyLFU 算法，命中率和读写性能优于 Guava Cache，是 Spring Boot 默认的本地缓存实现。