1. 缓存基础与演进：从本地缓存到分布式缓存，缓存的核心价值与挑战
1.1 缓存的核心价值：为什么需要缓存？
在软件架构中，缓存的核心思想是“用空间换时间”——将数据存储在更快的存储介质中，以减少对慢速存储（如数据库、磁盘）或远程服务的访问次数。缓存的价值体现在三个关键维度：
| 维度 | 说明 | 典型收益 |
|---|---|---|
| 降低延迟 | 内存访问延迟通常在微秒级（~100ns），而数据库查询延迟在毫秒级（1-100ms） | 响应时间降低 10-100 倍 |
| 提升吞吐量 | 缓存层可承受每秒数万到数十万次请求，减轻下游系统压力 | 系统 QPS 提升 5-20 倍 |
| 保护后端 | 缓存作为“缓冲垫”，防止突发流量击穿数据库或第三方服务 | 数据库连接数减少 80% 以上 |
经验法则： 缓存命中率低于 80% 时，需要重新评估缓存策略或数据模型。高命中率是缓存有效性的第一指标。
1.2 缓存架构的演进路线
缓存架构经历了从单机到分布式、从简单到复杂的演进过程。理解这条路线，有助于在 Spring Boot 项目中做出正确的技术选型。
- 阶段一：本地缓存（单机） — 数据存储在应用进程内，如 HashMap、Guava Cache、Caffeine。速度最快，但容量受限于 JVM 堆内存，且多实例间数据不一致。
- 阶段二：集中式缓存（主从） — 引入独立的缓存中间件（如 Redis 单机/主从），所有应用实例共享同一缓存池。解决了数据共享问题，但存在单点故障风险。
- 阶段三：分布式缓存（集群） — 采用 Redis Cluster、Codis、Memcached 集群等方案，数据分片存储，具备水平扩展能力。这是当前微服务架构的主流选择。
- 阶段四：多级缓存（混合） — 本地缓存 + 分布式缓存组合，兼顾速度与容量。例如 Caffeine（L1）+ Redis（L2），是高性能场景的终极方案。
架构决策要点： 在 Spring Boot 项目中，单实例开发环境可使用 Caffeine 本地缓存；生产多实例部署必须使用 Redis 等分布式缓存；超高并发场景（如秒杀、排行榜）建议采用多级缓存架构。
1.3 本地缓存 vs 分布式缓存：核心差异
在 Spring Boot 项目中，选择本地缓存还是分布式缓存，取决于应用部署架构和一致性要求。下表从多个维度进行对比：
| 对比维度 | 本地缓存（Caffeine / Guava） | 分布式缓存（Redis / Memcached） |
|---|---|---|
| 数据存储位置 | 应用进程 JVM 堆内 | 独立缓存服务器（内存） |
| 访问延迟 | < 0.1ms（无网络开销） | 1-5ms（网络往返） |
| 容量上限 | 受限于 JVM 堆大小（通常 < 8GB） | 可水平扩展至 TB 级 |
| 数据一致性 | 多实例间天然不一致 | 所有实例共享同一份数据 |
| 失效广播 | 需额外机制（如 Redis Pub/Sub） | 内置键空间通知 |
| 适用场景 | 只读配置、热点数据、单实例应用 | 多实例共享数据、会话、计数器 |
常见误区： 不要试图用本地缓存解决多实例间的数据一致性问题。即使使用 Caffeine 的
refreshAfterWrite 策略，也无法保证多个应用实例在同一时刻看到相同的数据版本。分布式场景必须引入 Redis 等集中式缓存。
1.4 缓存面临的核心挑战
缓存并非银弹。在实际工程中，缓存引入的复杂性往往超过其带来的性能收益。以下是缓存系统必须面对的四大核心挑战：
- 缓存穿透： 查询一个不存在的数据，缓存层无法命中，请求直接打到数据库。大量此类请求会导致数据库压力骤增。
- 缓存击穿： 某个热点 key 在缓存过期瞬间，大量并发请求同时访问该 key，全部穿透到数据库。
- 缓存雪崩： 大量 key 在同一时间过期，或缓存节点宕机，导致请求全部涌入数据库，引发连锁故障。
- 数据一致性： 数据库更新后，缓存未能及时同步，导致用户读到脏数据。这是缓存系统中最难解决的问题。
1.5 缓存一致性问题的根源
缓存一致性问题的本质是数据更新顺序的不确定性。在并发环境下，数据库更新和缓存更新无法保证原子性，导致以下三种典型的不一致场景：
- 先更新数据库，再更新缓存： 如果缓存更新失败，数据库是新数据，缓存是旧数据。
- 先删除缓存，再更新数据库： 在删除缓存后、更新数据库前，另一个线程读取到旧数据并写入缓存，导致缓存中始终是旧数据。
- 先更新数据库，再删除缓存： 这是目前业界推荐的“Cache-Aside”模式，但在高并发下仍存在短暂的不一致窗口。
课程核心观点： 缓存一致性没有银弹。在 Spring Boot 项目中，我们需要根据业务对一致性的容忍度，选择不同的策略：
• 强一致性场景（如支付、库存）：使用分布式锁 + 事务消息，或直接绕过缓存。
• 最终一致性场景（如用户资料、文章列表）：使用延迟双删 + 异步补偿。
• 弱一致性场景（如热搜、排行榜）：接受短暂不一致，依靠缓存过期自动修复。
• 强一致性场景（如支付、库存）：使用分布式锁 + 事务消息，或直接绕过缓存。
• 最终一致性场景（如用户资料、文章列表）：使用延迟双删 + 异步补偿。
• 弱一致性场景（如热搜、排行榜）：接受短暂不一致，依靠缓存过期自动修复。
1.6 本章小结
缓存是性能优化的第一手段，但也是复杂性的主要来源。本章我们建立了缓存的基础认知框架：
- 缓存的核心价值在于降低延迟、提升吞吐量、保护后端系统。
- 缓存架构从本地缓存演进到多级缓存，每种方案都有其适用边界。
- 本地缓存与分布式缓存的本质差异在于数据共享与一致性。
- 缓存穿透、击穿、雪崩、一致性是必须解决的四大挑战。
- 一致性问题的根源是数据库与缓存的更新顺序无法原子化。