## 01、痛点

上周凌晨两点，商品详情接口报警，数据库 CPU 飙到 95%。我是老李，第一反应是缓存是不是又“漏”了。打开监控一看，缓存命中率从 96% 掉到 31%，大量请求直接打到 MySQL，数据库连接池被打满，商品详情页转圈十几秒。

这不是第一次。团队里很多人觉得缓存就是加一个 @Cacheable 注解，方法返回结果自动缓存，下次直接走缓存。看起来没毛病，但商品详情这种读多写少的场景，偏偏在促销、秒杀、运营改价、库存变化时出问题。缓存穿透、击穿、雪崩，三个词分开都懂，合在一起就变成线上事故。

为什么现在要讲？因为缓存是性能优化里最容易被低估的部分。表面上是“查不到就查库，然后放缓存”，但真正生产环境里，你要同时面对数据一致性、并发回源、热点倾斜、大 Key 阻塞、Redis 抖动、数据库主从延迟。缓存的本质不是某个注解，而是在性能、数据一致性和系统复杂度之间做 Trade-off。这一章，我们把这件事从头到尾讲清楚。

## 02、是什么

缓存，说白了就是空间换时间。把一份数据副本放到离调用方更近、访问更快的地方，比如 Redis、本地内存、CDN。读取路径从“业务 -> 数据库”变成“业务 -> 缓存 -> 数据库”。好处是减少数据库压力、降低响应时间；代价是多了一份数据，数据可能不一致，而且系统多了一个组件要维护。

但这只是表面。真正的缓存设计，是在三个目标之间找平衡：
- 性能：命中率要高，回源要少；
- 数据一致性：缓存数据和数据库数据不能差得太离谱；
- 系统复杂度：引入缓存后，代码、运维、监控、容灾都要跟着升级。

围绕这个平衡，业界沉淀出四类经典写入策略：

Cache Aside，也叫旁路缓存。读的时候先读缓存，缓存没命中就读数据库，然后把结果写回缓存。写的时候直接更新数据库，然后删除缓存。这个策略最常见，Spring Boot 里手动用 RedisTemplate 就能实现。

Read Through，读穿透。缓存层负责读数据库并回填，业务代码只跟缓存打交道。像本地缓存库或某些 CacheManager 封装了加载逻辑。

Write Through，写穿透。写入时同时更新缓存和数据库，保证缓存和数据库同步。适合读多写多但一致性要求高的场景，但每次写都动缓存，性能有损耗。

Write Behind，异步写回。写入时只更新缓存，然后异步批量刷到数据库。性能最好，但丢数据风险最大，一致性最弱。

这四种策略没有银弹。商品详情这种典型场景，用 Cache Aside 最合适：读多写少，写操作大多是运营改价、库存扣减，删缓存比更新缓存更简单，也能避免缓存和数据库双写的顺序问题。

## 03、为什么

为什么一套缓存方案值得单独拿出来讲？因为缓存问题不是“有没有缓存”，而是“缓存失效的那一刻系统会怎样”。你观察一下线上故障，很多不是常态流量打挂的，而是缓存集体失效后，流量瞬间穿透到数据库。

常见的问题有五个：

缓存穿透：请求查一个数据库里根本不存在的数据，比如商品 ID 传 -1 或随机字符串。缓存没有，数据库也没有，每次请求都打到数据库。攻击者可以用这个方式把数据库打挂。

缓存击穿：一个热 Key 过期，大量并发请求同时回源数据库。比如爆款商品详情缓存刚好过期，几万 QPS 同时查库，数据库瞬间压力巨大。

缓存雪崩：大量 Key 在同一时间过期，或者 Redis 集群抖动不可用，导致请求大面积回源。和击穿的区别是，击穿是单点热点，雪崩是面状失效。

热 Key：某一个 Key 访问量极高，比如头部商品、明星动态。大量请求集中在一个 Redis 分片，可能把该分片打满，甚至影响同分片其他 Key。

大 Key：某个 Key 的 value 很大，比如商品详情里存了几 MB 的富文本、图片列表、SKU 嵌套。读写大 Key 会阻塞 Redis 单线程，网络传输也慢，还容易引发内存碎片。

这些问题不是独立出现的。一个促销活动可能同时触发：流量上涨 -> 热 Key 过期 -> 击穿 -> 多个热 Key 连续过期 -> 雪崩 -> 数据库崩了 -> 缓存回源失败 -> 全链路雪崩。所以我们要系统学缓存策略，而不是只背概念。

## 04、架构

在 Spring Boot 里，缓存架构通常分成三层：

第一层，业务服务。商品详情服务接收请求，先查缓存，再查数据库，再回填。这里可以选择手动用 RedisTemplate 控制每一步，也可以交给 Spring Cache 抽象。

第二层，缓存访问层。Spring Data Redis 提供了两套东西：一套是底层的 RedisTemplate，让你像操作 Redis 命令一样操作缓存；另一套是 Spring Cache 抽象，通过 RedisCacheManager 把缓存逻辑声明式地接入业务方法。

第三层，Redis 集群。生产环境一般用主从、哨兵或 Cluster，保证高可用和扩展性。

为什么要区分 RedisTemplate 和 RedisCacheManager？因为它们解决的是不同层次的问题。

RedisTemplate 是命令式工具，你可以精确控制 key、value、TTL、序列化方式、是否删除、是否回填。适合复杂策略，比如 Cache Aside、随机 TTL、空对象缓存、单飞锁。缺点是代码量多一些，每个缓存读写都要自己写。

RedisCacheManager + @Cacheable 是声明式缓存，代码侵入小，适合简单场景。但它的默认行为比较粗：默认 TTL 统一，Key 生成规则固定，缓存 null 需要额外配置，删除缓存靠 @CacheEvict。遇到穿透、击穿、雪崩需要自己扩展。

我们的建议是：核心链路用 RedisTemplate 手动实现策略，因为你要完全掌控数据一致性；非核心、容忍不一致的查询可以用 Spring Cache 注解简化。

## 05、实战

下面我们用一个商品详情接口来落地。需求是这样：根据 productId 查询商品详情，包含基础信息、SKU、库存、价格、图片。读多写少，要求缓存命中率 95% 以上，数据库不能被打挂。

先定义缓存 Key 和 TTL。Key 用 product:detail:{productId}。TTL 不要固定 30 分钟，可以在 25 到 35 分钟之间随机，避免同一批商品同时过期，造成雪崩。

手动 RedisTemplate 实现 Cache Aside 的读取逻辑：

```
public ProductDetail getProductDetail(Long productId) {
    String key = "product:detail:" + productId;
    String json = redisTemplate.opsForValue().get(key);
    if (json != null) {
        return JSON.parseObject(json, ProductDetail.class);
    }
    // 单飞锁，防止击穿
    String lockKey = "lock:product:detail:" + productId;
    boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
    if (Boolean.TRUE.equals(locked)) {
        try {
            // 双重检查
            json = redisTemplate.opsForValue().get(key);
            if (json != null) {
                return JSON.parseObject(json, ProductDetail.class);
            }
            ProductDetail detail = productRepository.findById(productId);
            if (detail != null) {
                int ttl = 25 + new Random().nextInt(10); // 25-35分钟随机
                redisTemplate.opsForValue().set(key, JSON.toJSONString(detail), ttl, TimeUnit.MINUTES);
                return detail;
            } else {
                // 空对象缓存，防穿透
                redisTemplate.opsForValue().set(key, "NULL", 5, TimeUnit.MINUTES);
                return null;
            }
        } finally {
            redisTemplate.delete(lockKey);
        }
    } else {
        // 没抢到锁，短暂等待后重试
        Thread.sleep(100);
        return getProductDetail(productId);
    }
}
```

这里的关键点：
- 随机 TTL：25 到 35 分钟随机，防止雪崩。
- 空对象缓存：数据库没有的商品，缓存一个特殊值 "NULL"，TTL 5 分钟，防止穿透。
- 单飞锁：setIfAbsent 抢锁，只有抢到锁的请求回源数据库，其他请求等待重试，防止击穿。

写操作采用先更新数据库，再删除缓存：

```
@Transactional
public void updateProduct(ProductDetail detail) {
    productRepository.update(detail);
    redisTemplate.delete("product:detail:" + detail.getProductId());
    // 延迟双删可选：延迟 1 秒再删一次
}
```

为什么删缓存而不是更新缓存？因为更新缓存容易出现并发写覆盖，而且缓存里的字段可能非原子更新。删缓存后，下次读会回源生成最新数据。

如果团队想用 Spring Cache 简化非核心查询，可以这样配置 RedisCacheManager：

```
@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
    RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(30))
        .serializeKeysWith(SerializationPair.fromSerializer(new StringRedisSerializer()))
        .serializeValuesWith(SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));
    return RedisCacheManager.builder(factory)
        .cacheDefaults(config)
        .build();
}
```

然后在方法上：

```
@Cacheable(value = "product:brief", key = "#productId")
public ProductBrief getProductBrief(Long productId) { ... }
```

但注意，这种注解方式默认不解决穿透和击穿，如果要生产级，需要自定义 CacheErrorHandler、KeyGenerator、TTL 随机化，甚至包装一个带锁的 CacheManager。核心商品详情链路，建议还是用 RedisTemplate 手动控制。

## 06、洞见

回到开头测验里的两个问题。

第一个：数据库更新成功但 Redis 删除失败怎么办？

这种情况一旦发生，缓存里还是旧数据，数据库已经是新数据。用户看到的价格、库存是旧的，可能造成超卖或资损。解决思路有几个：
- 重试删除：把删除操作放到一个带重试的任务里，失败后间隔重试多次。
- 延迟双删：更新数据库后先删缓存，延迟几百毫秒再删一次，减少并发读写窗口。
- 订阅 binlog：监听数据库变更，异步删除缓存，比如用 Canal 或 Debezium 把变更事件推送到消息队列，消费者删除缓存。这样即使第一次删除失败，binlog 还会驱动后续删除。
- 版本号：缓存里存数据版本，数据库更新时版本号递增，读缓存时校验版本，旧版本主动失效。

第二个：为什么“先更新数据库，再删缓存”仍然不是绝对一致？

假设两个并发请求：请求 A 读数据，请求 B 写数据。时间线如下：

1. 请求 A 读缓存，未命中；
2. 请求 A 查数据库，得到旧值；
3. 请求 B 更新数据库为新值；
4. 请求 B 删除缓存；
5. 请求 A 把旧值写回缓存。

结果缓存里是旧值，但数据库是新值。这个窗口期很短，但不是零。所以“先更新数据库，再删缓存”只是把不一致概率降到很低，无法做到绝对一致。

要解决这个窗口，可以用延迟双删：请求 B 更新数据库后删缓存，等待一段时间再删一次；或者使用分布式读写锁，让读回源和写更新互斥；或者在缓存里存版本号，写回时校验版本，旧版本不允许覆盖。实际生产里，大部分业务能容忍短暂不一致，所以先更新数据库再删缓存 + 延迟双删 + binlog 补偿，基本够用。但涉及库存、余额等强一致链路，不能只靠缓存，要回源数据库或加锁。

所以，缓存的本质是 Trade-off：你要性能，就必须接受短暂不一致；你要强一致，就必须牺牲性能。缓存不能代替数据库成为最终事实来源。

## 07、行动

学到这里，不是把代码抄一遍就完了。建议按下面步骤落地：

第一步，梳理缓存边界。哪些接口读多写少、能容忍短暂不一致，哪些不能。商品详情、内容页、配置类适合缓存；库存扣减、支付、账户余额不适合。

第二步，选择策略。读多写少用 Cache Aside；缓存层封装完整用 Read/Write Through；日志、计数等允许丢失用 Write Behind。

第三步，防住典型问题。穿透上空对象或布隆过滤器；击穿上单飞锁；雪崩上随机 TTL 和集群高可用；热 Key 上本地缓存或多副本；大 Key 要拆分，避免大 value。

第四步，监控先行。缓存命中率、回源 QPS、Redis 延迟、内存淘汰、过期 Key 数量、慢查询日志，这些指标必须可见，否则出了事就是黑盒。

第五步，灰度并压测。上线缓存策略前，先在灰度环境模拟穿透、击穿、雪崩，观察数据库压力。压测时重点看缓存过期瞬间的流量尖峰。

第六步，写操作兜底。数据库更新后删除缓存失败要有重试和补偿，核心场景建议订阅 binlog 做最终一致。

第七步，文档沉淀。把 Key 规范、TTL 规则、序列化方式、回源策略写清楚，避免每个开发各写一套。

## 08、小结

这一章，我们从一次商品详情缓存事故讲起，系统整理了缓存设计的核心：缓存不是 @Cacheable，而是性能、一致性和复杂度之间的权衡。四种写入策略各有适用场景，商品详情用 Cache Aside 最合适。穿透、击穿、雪崩、热 Key、大 Key 是五个必须解决的问题。Spring Boot 里，RedisTemplate 提供精确控制，Spring Cache 提供声明式简化，核心链路推荐前者。最后，缓存一致性没有绝对方案，先更新数据库再删缓存也只是概率收敛，需要用延迟双删、binlog 补偿、版本号等手段兜底。

把这一套搞清楚，比会写 @Cacheable 值钱得多。下一章我们再深入缓存集群和容量规划。

## 09、链接与概念说明

- Cache Aside：旁路缓存，读缓存未命中回源，写数据库后删缓存。
- Read Through：读穿透，缓存层自动加载数据库并回填。
- Write Through：写穿透，写操作同步更新缓存和数据库。
- Write Behind：异步写回，先写缓存，异步刷数据库，性能高但可能丢数据。
- 缓存穿透：查询不存在的数据，每次回源。
- 缓存击穿：热 Key 过期，大量并发回源单点。
- 缓存雪崩：大量 Key 同时过期或缓存集群不可用，请求大面积回源。
- 热 Key：访问量极高的单个 Key。
- 大 Key：value 过大的 Key，影响 Redis 单线程和网络传输。
- Redis 官方文档和 Spring Data Redis 官方文档可查看 Key、TTL、RedisCacheManager 的详细参数。

上周凌晨两点，商品详情接口报警，数据库 CPU 飙到 95%。我是老李，第一反应是缓存是不是又“漏”了。打开监控一看，缓存命中率从 96% 掉到 31%，大量请求直接打到 MySQL，数据库连接池被打满，商品详情页转圈十几秒。

《Redis 8.10 + Spring Boot 实战》第7招 缓存架构——真正难的不是 Redis，而是缓存一致性

从商品详情接口出发，系统拆解缓存四大写入策略与五大典型问题，并用 Spring Boot 落地 Cache Aside、随机 TTL、空对象和单飞锁。

架构师

编程语言

商品详情缓存架构的完整实战指南，深入解析CacheAside、缓存穿透/击穿/雪崩的解决方案。提供SpringBoot RedisTemplate和SpringCache具体代码实现，涵盖随机TTL、单飞锁、空对象缓存、延迟双删等核心策略。重点讲解缓存一致性权衡、性能优化与生产级监控要点，帮助开发者构建高可用缓存系统。

数据库连接池

数据一致性

消息队列

代码解释

数据库

容灾

MySQL

Redis

JSON

CDN免费试用


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第7招 缓存架构——真正难的不是 Redis，而是缓存一致性-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第7招缓存架构——真正难的不是 Redis，而是缓存一致性

《Redis 8.10 + Spring Boot 实战》第7招缓存架构——真正难的不是 Redis，而是缓存一致性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第7招 缓存架构——真正难的不是 Redis，而是缓存一致性

《Redis 8.10 + Spring Boot 实战》第7招 缓存架构——真正难的不是 Redis，而是缓存一致性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第7招缓存架构——真正难的不是 Redis，而是缓存一致性

《Redis 8.10 + Spring Boot 实战》第7招缓存架构——真正难的不是 Redis，而是缓存一致性