获课：xingkeit.top/6770/

分布式缓存设计：多级缓存架构优化 Java 项目接口响应速度

Java 后端项目遇到性能瓶颈时，第一反应往往是加缓存。但只加一层 Redis 就够了吗？当 QPS 冲到几万甚至更高，单点缓存会变成新的瓶颈。多级缓存架构才是应对高并发的正解。

单层缓存为什么不够用

大部分项目的缓存方案是"请求 → Redis → 数据库"。这在低并发时完全够用，但有两个致命问题：

第一，网络开销。 每次请求都要经过一次网络调用到 Redis，即使 Redis 只需 1 毫秒，在高并发下这 1 毫秒也会累积成可观的延迟。

第二，缓存击穿。 当某个热点 key 过期的瞬间，大量请求同时打到数据库，数据库瞬间崩溃，整个接口瘫痪。

单层缓存既扛不住并发，也扛不住异常。

多级缓存的架构设计

多级缓存的核心思路是把数据放在离请求最近的地方，层级越靠前，速度越快，但容量越小。

第一级：本地缓存（JVM 堆内）。 用 Caffeine 或 Guava Cache，数据直接存在应用进程的内存里，访问速度是纳秒级，零网络开销。但缺点明显——每个节点一份数据，节点间不共享，重启后数据丢失。适合存高频访问、变更不频繁的数据，比如商品类目、配置信息、热门榜单。

第二级：分布式缓存（Redis）。 当本地缓存未命中时，查 Redis。Redis 承担的是共享缓存的角色，所有节点看到的数据一致。适合存热点商品详情、用户会话、短期计数等需要跨节点共享的数据。

第三级：数据库。 缓存全部未命中时，才回源到数据库。这一层是兜底，不是主力。

三级之间用"先查本地，再查 Redis，最后查库"的顺序串联，命中率越高，接口响应越快。

关键问题怎么解决

本地缓存与 Redis 的一致性。 这是多级缓存最大的难题。本地缓存更新了，Redis 没更新，用户看到的就是旧数据。常见方案有两种：一是设置较短的本地过期时间，比如 30 秒，牺牲一点一致性换取简单；二是用消息队列广播失效通知，所有节点收到消息后清除本地缓存，一致性更强但复杂度更高。实际项目中，30 秒的延迟对大部分业务完全可接受。

缓存穿透怎么防。 查询一个根本不存在的数据，缓存和数据库都没有，每次都打到库上。解法是给不存在的 key 也缓存一个空值，设置较短的过期时间，比如 60 秒。这样同一个不存在的 key 在 60 秒内不会再穿透到数据库。

缓存雪崩怎么防。 大量 key 同时过期，瞬间全部打到数据库。解法是给过期时间加随机偏移，比如原本设置 1 小时过期，实际设置 1 小时加 0 到 5 分钟的随机值，让过期时间分散开，避免集中击穿。

什么时候该上多级缓存

不是所有项目都需要。如果接口 QPS 只有几百，单层 Redis 足够。但当你发现 Redis CPU 持续飙高、接口 P99 延迟开始抖动、数据库连接池频繁告警时，就是该上多级缓存的信号。

多级缓存的本质不是堆技术，而是用空间换时间，用复杂度换稳定性。本地缓存扛住热点，Redis 扛住共享，数据库只兜底。三层各司其职，接口响应速度才能真正扛住高并发。