SpringBoot 结合 Redis+Caffeine 多级缓存实战解析

实现流程

1. 配置数据源：在 application.yml 中设置地址、账号及连接池参数；
2. 定义实体类：映射表结构，利用注解简化配置；
3. 编写 Mapper：继承 BaseMapper 即可实现 CRUD，无需手写 SQL；
4. 封装 Service：处理校验、权限等逻辑；
5. 暴露接口：使用 @RestController 定义路径。

此方案开发效率高且数据一致性好，但面对海量并发时，仍需缓存介入。

多级缓存逻辑：Redis + Caffeine

多级缓存的核心在于'近缓存优先'。Caffeine 作为进程内缓存，延迟极低；Redis 作为分布式缓存，支持集群共享。两者结合兼顾速度与一致性。

组件对比

工作流程

基于 Spring Cache 抽象整合两者，查询顺序如下：

1. 查本地缓存（Caffeine），命中直接返回；
2. 未命中则查分布式缓存（Redis），命中后回填本地并返回；
3. 仍未命中则查数据库，结果同步至 Redis 和本地缓存；
4. 更新数据时，先更库再删缓存，防止不一致。

以下是一个分页列表接口的多级缓存实现示例：

/**
 * 采用多级缓存，先查询本地缓存，如果本地缓存查询不到，在查询分布式缓存，如果再没有再从数据库中查询
 */
@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) {
    // ... 参数校验与构造 Key ...
    String queryCondition = DigestUtils.md5DigestAsHex(JSONUtil.toJsonStr(pictureQueryRequest).getBytes());
    String cacheKey = String.format("hututu:listPictureVOByPageWithCache:%s", queryCondition);

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

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

    // 3. 查询 mysql
    pictureVOPage = pictureService.getPictureVOPage(...);

    // 4. 回写缓存
    localCacheWithCaffeine.put(cacheKey, JSONUtil.toJsonStr(pictureVOPage));
    stringValueWithRedisTemplate.set(cacheKey, JSONUtil.toJsonStr(pictureVOPage), 300, TimeUnit.SECONDS);

    return ResponseUtil.success(pictureVOPage);
}

优势与劣势分析

技术方案无绝对优劣，需结合场景评估。

核心优势

• 极致性能：Caffeine 覆盖高频查询，大幅降低网络开销。实测接口响应可从 50ms 降至 1-5ms。
• 分布式适配：Redis 保证多实例间一致性，Caffeine 减少跨服务竞争。
• 高可用兜底：Redis 故障时，本地缓存可作为临时保障，避免雪崩。

主要劣势

• 复杂度提升：需维护两套缓存配置及一致性逻辑。
• 资源消耗：JVM 堆内存与独立服务器资源占用增加。
• 一致性风险：多实例间存在短暂数据不一致窗口，需通过发布订阅或过期机制缓解。

适用场景与实践注意点

核心场景

• 高频读低频写：如商品详情、配置字典。
• 分布式微服务：减少服务间调用与网络开销。
• 高并发核心接口：秒杀、限时优惠等瞬时流量大的场景。

关键实践

• 合理配置：Caffeine 设置 LRU/LFU 淘汰策略，避免 OOM；Redis 开启持久化并防护热点 Key。
• 一致性保障：推荐'先更库再删缓存'；强一致性场景可用 Pub/Sub 通知失效。
• 常见问题规避：
  • 穿透：缓存空值或布隆过滤器。
  • 击穿：热点 Key 互斥锁或永不过期。
  • 雪崩：过期时间加随机偏移，集群部署。
• 监控运维：关注命中率与内存使用率，设置告警阈值。

总结

Spring+MySQL 是基础，Redis+Caffeine 多级缓存则是应对高并发的利器。它通过'本地 + 分布式'组合平衡了性能与一致性，但也引入了复杂度。实践中应依据业务读写频率选择方案，配合合理的配置与监控，确保系统稳定。