SpringBoot 多级缓存实战：Redis 与 Caffeine 结合优化 API 性能

1.2 核心实现流程

首先，我们需要在 application.yml 中配置好 MySQL 的连接信息、用户名、密码及连接池参数。接着定义实体类，对应 MySQL 数据表结构，使用 MyBatis-Plus 注解简化配置。编写 Mapper 接口继承 BaseMapper 即可实现 CRUD 操作，无需手动编写 SQL。随后在 Service 层封装业务逻辑，如数据校验、权限控制等。最后通过 Controller 暴露接口，利用 @RestController、@RequestMapping 等注解定义 API 路径，接收请求并返回结果。

该架构的优势在于开发效率高、数据一致性强，但当并发请求量超过 MySQL 承载能力时，会出现查询延迟、连接池耗尽等问题，此时缓存的引入至关重要。

二、多级缓存：Redis+Caffeine 的组合逻辑

多级缓存的核心思路是'近缓存优先'，将访问频率高的数据存储在距离应用更近的缓存中，减少网络开销和数据库压力。Caffeine 作为本地缓存（进程内缓存），Redis 作为分布式缓存（独立服务），二者结合可兼顾性能与分布式一致性。

<!-- 分布式缓存：redis -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- 本地缓存：caffeine (注意：3.x 版本 java 版本至少要在 11 以上) -->
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.8</version>
</dependency>

2.1 组件特性对比

2.2 多级缓存工作流程

基于 Spring Cache 抽象，可快速整合 Caffeine 与 Redis，核心流程如下：

1. 查询缓存：请求到达后，先查询 Caffeine 本地缓存，若命中直接返回数据；
2. 分布式缓存查询：若 Caffeine 未命中，查询 Redis 分布式缓存，若命中则将数据同步到 Caffeine 后返回；
3. 数据库查询：若 Redis 也未命中，查询 MySQL 数据库，将查询结果同步到 Redis 和 Caffeine 后返回；
4. 缓存更新/失效：当数据发生修改时，先更新数据库，再删除对应 Redis 和 Caffeine 缓存（避免缓存与数据库不一致）。

这里有一段关键的业务逻辑代码示例，展示了如何实现分页列表的多级缓存：

/**
 * 采用多级缓存，先查询本地缓存，如果本地缓存查询不到，再查询分布式缓存，
 * 如果还没有再从数据库中查询
 */
@Resource
private ValueOperations<String, String> stringValueWithRedisTemplate;

@Resource
private Cache<String, String> localCacheWithCaffeine;

@PostMapping("/list/page/vo/multi-level")
public BaseResponse<Page<PictureVo>> listPictureVOByPageWithMultiLevel(
        @RequestBody PictureQueryRequest pictureQueryRequest,
        HttpServletRequest request) {
    int current = pictureQueryRequest.getCurrent();
    int pageSize = pictureQueryRequest.getPageSize();
    ThrowUtil.throwIf(pageSize > 20, ResponseCode.PARAMS_ERROR);

    // 只有审核过的图片可以在主页显示
    pictureQueryRequest.setReviewStatus(ReviewStatusEnum.PASS.getValue());
    Page<Picture> picturePage = pictureService.page(new Page<>(current, pageSize), 
            pictureService.getQueryWrapper(pictureQueryRequest));

    // 1. 构造 key
    String queryCondition = JSONUtil.toJsonStr(pictureQueryRequest);
    // 查询条件加密
    queryCondition = DigestUtils.md5DigestAsHex(queryCondition.getBytes());
    String cacheKey = String.format("hututu:listPictureVOByPageWithCache:%s", queryCondition);

    // 2. 先查询本地缓存
    String cacheValue = localCacheWithCaffeine.getIfPresent(cacheKey);
    Page<PictureVo> pictureVOPage = null;
    if (cacheValue != null) {
        pictureVOPage = JSONUtil.toBean(cacheValue, Page.class);
        return ResponseUtil.success(pictureVOPage);
    }

    // 3. 查询 redis 缓存
    cacheValue = stringValueWithRedisTemplate.get(cacheKey);
    if (cacheValue != null) {
        pictureVOPage = JSONUtil.toBean(cacheValue, Page.class);
        return ResponseUtil.success(pictureVOPage);
    }

    // 4. 查询 mysql
    pictureVOPage = pictureService.getPictureVOPage(picturePage, request);

    // 5. 存储本地缓存和 redis 缓存
    localCacheWithCaffeine.put(cacheKey, JSONUtil.toJsonStr(pictureVOPage));
    // 注意：这里设置的是 cacheKey，而不是之前获取的 cacheValue
    stringValueWithRedisTemplate.set(cacheKey, JSONUtil.toJsonStr(pictureVOPage), 
            300 + RandomUtil.randomInt(0, 300), TimeUnit.SECONDS);
    return ResponseUtil.success(pictureVOPage);
}

三、多级缓存的优势与劣势

任何技术方案都有其适用场景，多级缓存的优劣需结合业务场景客观评估。

3.1 核心优势

3.1.1 极致的性能提升

Caffeine 的微秒级访问延迟可覆盖大部分高频查询场景，减少对 Redis 的网络调用；Redis 则承接跨服务的缓存需求，二者结合使缓存命中率大幅提升，数据库查询压力显著降低。实测显示，在商品详情查询场景中，引入多级缓存后接口响应时间可从 50-100ms 降至 1-5ms，并发承载能力提升 10 倍以上。

3.1.2 分布式场景适配

在微服务架构中，Caffeine 的本地缓存可减少服务间对 Redis 的竞争，而 Redis 确保了不同服务实例间的缓存一致性。例如，用户登录状态缓存可存储在 Redis 中供所有服务访问，而服务本地的高频配置数据可存储在 Caffeine 中，兼顾一致性与性能。

3.1.3 高可用性保障

当 Redis 集群因网络故障或节点宕机暂时不可用时，Caffeine 本地缓存可作为'兜底缓存'，保障核心接口的可用性；反之，若单个服务实例故障，Redis 中的缓存数据可被其他实例复用，避免缓存雪崩。

3.2 主要劣势

3.2.1 架构复杂度提升

引入多级缓存后，需额外维护 Caffeine 的本地缓存配置（如容量、过期时间、淘汰策略）和 Redis 的集群部署、持久化策略；同时需处理缓存一致性问题（如更新/删除时的缓存同步），增加了开发和运维成本。

3.2.2 内存资源消耗增加

Caffeine 缓存占用 JVM 堆内存，若配置不当（如容量过大、淘汰策略不合理），易导致 JVM 内存溢出（OOM）；Redis 集群则需独立的服务器资源，增加了硬件成本。

3.2.3 数据一致性风险

多级缓存存在'缓存不一致'的天然风险：例如，服务 A 更新数据后删除了自身 Caffeine 缓存和 Redis 缓存，但服务 B 的 Caffeine 缓存中仍有旧数据，直到过期才会更新。虽可通过发布订阅机制（如 Redis Pub/Sub）触发全量服务的本地缓存失效，但会增加系统复杂度。

四、适用场景与实践注意点

4.1 核心适用场景

4.1.1 高频读、低频写场景

如商品详情、新闻资讯、字典配置等数据，查询频率远高于更新频率，多级缓存可最大化发挥性能优势。例如，电商平台的商品列表查询，90% 以上的请求可通过 Caffeine 命中，剩余请求通过 Redis 命中，仅极少数请求需查询数据库。

4.1.2 分布式微服务架构

微服务间的接口调用频繁，多级缓存可减少跨服务依赖和网络开销。例如，订单服务查询用户信息时，先查本地 Caffeine 缓存，未命中再查 Redis 缓存，最后调用用户服务接口并同步缓存，降低服务间的耦合度。

4.1.3 高并发核心接口

如秒杀活动、限时优惠等场景，并发量可达数万 QPS，单一数据库或 Redis 无法承载。多级缓存可通过 Caffeine 承接大部分瞬时请求，Redis 保障分布式一致性，数据库仅处理最终的下单逻辑。

4.2 关键实践注意点

4.2.1 合理配置缓存策略

• Caffeine 配置：建议设置最大容量（如 10000 条）、过期时间（如 5 分钟），采用 LRU（最近最少使用）或 LFU（最不经常使用）淘汰策略；避免缓存超大对象（如超过 1MB），防止 JVM 内存碎片化。
• Redis 配置：采用集群部署（如 3 主 3 从）保障高可用，开启 AOF 持久化避免数据丢失；针对热点数据设置合理的过期时间（如 10 分钟），并通过'热点 Key'防护机制避免缓存击穿。

4.2.2 保障数据一致性

采用'先更新数据库，再删除缓存'的策略（避免更新缓存失败导致不一致）；对于强一致性需求场景，可引入 Redis Pub/Sub 机制，当数据更新时，发布缓存失效消息，所有服务实例接收消息后删除本地 Caffeine 缓存；对于弱一致性场景，可依赖缓存过期机制自然失效。

4.2.3 避免缓存常见问题

• 缓存穿透：请求不存在的数据
  • 对不存在的 Key，在 Redis 中缓存空值（设置短过期时间，如 10 秒），并结合布隆过滤器过滤无效 Key；
• 缓存击穿：请求不存在的热点数据
  • 对热点 Key 设置'永不过期'，通过后台线程定期更新；或采用互斥锁机制，确保同一时间仅一个请求查询数据库；
• 缓存雪崩：大量缓存同时过期
  • 将缓存过期时间设置为'基础时间 + 随机偏移'（如 10 分钟±30 秒），避免大量缓存同时失效；Redis 集群采用多区域部署，避免单点故障。

4.2.4 监控与运维保障

通过 Spring Boot Actuator 监控 Caffeine 缓存命中率、容量使用情况；通过 Redis 监控工具（如 Redis Insight）监控 Redis 的命中率、内存占用、集群状态；设置告警机制，当缓存命中率低于阈值（如 80%）或 Redis 内存使用率超过阈值（如 80%）时及时预警。

五、总结

Spring+MySQL 是 API 接口开发的基础架构，而 Redis+Caffeine 多级缓存则是应对高并发场景的'性能利器'。其核心价值在于通过'本地缓存 + 分布式缓存'的组合，兼顾了性能、一致性与可用性，但同时也带来了架构复杂度和资源消耗的提升。

在实践中，需结合业务场景选择是否引入多级缓存：对于低频请求、强一致性需求的接口，单一数据库或 Redis 缓存即可满足需求；对于高频读、低频写的核心接口，多级缓存则能带来显著的性能提升。同时，需通过合理的缓存配置、一致性策略和监控机制，规避潜在风险，确保系统稳定运行。