Caffeine+Redis多级缓存架构实战：解决高QPS热点与缓存雪崩难题

做后端时间久了你会发现，真正把系统压垮的往往不是数据库，而是你引以为傲的那一层缓存。

我参与维护过的一个购物类应用，商品详情接口平时QPS也就两三千，一次活动预热直接把流量顶到了两万。当时第一反应是Redis顶得住，毕竟“单实例10万级QPS”的说法谁都在讲。结果压测还没结束，Redis的CPU先冲上了90%，应用侧超时一个接一个。排查了半天，问题不在Redis本身，而是一个商品ID的热度超过了总流量的80%——所有请求都在打同一个Key，Redis再强也扛不住这种集中火力。

后面我把缓存架构改成了两层：JVM内的Caffeine做第一层，Redis做第二层，数据库垫底。同样的流量，Redis的QPS从两万降到了两千以内，接口平均响应时间从十几毫秒压到了三毫秒左右。这篇实战指南就围绕 Caffeine + Redis 多级缓存 架构展开，我会把两级缓存的分工、参数调优、数据一致性、穿透击穿雪崩防护以及压测数据都整理出来，给正在做类似改造的同学一条可以直接参考的路线。

1. 先算清楚延迟账：两级缓存到底在解决什么问题

1.1 单Redis扛不住高QPS的真相

很多人对Redis的认知停留在“单实例能扛10万QPS”，这话在理想条件下没错，但生产环境从来不是理想条件。Redis本身是单线程处理命令，热点一旦集中到某一个Key上，分片再均匀也救不了你——流量全打在一个分片上，那个分片的CPU就是会先爆。

比热点更隐蔽的问题是网络往返。每次读Redis都是一次完整的TCP交互，应用线程要等一个RTT。QPS到两万的时候，每秒就是两万次网络往返，加上连接池里线程被占住的时间，瓶颈根本不在Redis的计算能力，而在网络IO的吞吐上限和连接池的周转速度。我当时看到的现象就是：Redis实例CPU没到100%，但客户端连接池已经打满，新请求全在等连接。

1.2 本地内存、Redis、数据库的延迟差距

把三种访问路径的耗时放在一起看，差距是数量级的。

本地内存比Redis快一到两个数量级，比数据库快三个数量级以上。这个差距的根源只有一个：本地缓存压根不产生网络IO。同样的读请求，走Caffeine只需要一次堆内存访问，走Redis要经过应用层序列化、内核缓冲区、网络传输、Redis端反序列化处理，再原路返回。延迟账算到这里，多级缓存的意义就很清楚了——把90%以上的读请求拦截在网卡之前。

1.3 两级缓存的分工：谁扛热点、谁挡流量、谁兜底

多级缓存不是简单地在Redis前面再套一个缓存，而是让每一层干自己最擅长的事。

• 第一层 Caffeine：部署在每个应用实例的JVM内，数据不跨节点共享。它的职责是挡住绝对热点和大部分重复读，把发往Redis的请求量降一个数量级。
• 第二层 Redis：多个实例共享一份数据，承接本地缓存miss后的流量，避免读请求直接打穿到数据库。
• 数据库：只承受写流量和极小比例的读miss。

这里面最妙的一点是：热点key问题在两级缓存架构下天然被化解了。同一个热点商品在六个应用实例里各有一份Caffeine副本，Redis分片上收到的热度请求被稀释成了六分之一甚至更少。你要知道，热点key在Redis层是拿分布式缓存没办法解决的经典难题，加一层本地缓存反而解决了。

2. Caffeine本地缓存：参数背后都是取舍

2.1 为什么选Caffeine而不是Guava Cache

Guava Cache是很多老项目的标配，成熟稳定，但Caffeine在淘汰算法上做了根本性升级。Caffeine用的是Window TinyLFU（窗口计数最小频繁使用）算法，它对短时间内的访问频率有专门记录窗口，能更好地识别“突然热起来”的key，而Guava的LRU在面对热点快速切换时，经常把刚刚热起来的key提前淘汰掉，或者在批量顺序扫描时让缓存抖动得厉害。

在高并发场景下，Caffeine的吞吐也明显好于Guava，而且内置了recordStats()这样的统计能力，命中率、淘汰次数都能直接拿到。如果只是几十个QPS的小服务，选哪个都无所谓；一旦上了万级并发，Caffeine在热点识别和命中率上的优势是会直接体现在压测数字上的。

2.2 核心参数配置与内存估算

一个比较常用的Caffeine配置长这样：

@Configuration public class LocalCacheConfig { @Bean public Cache<String, Product> localCache() { return Caffeine.newBuilder() .initialCapacity(200) .maximumSize(20_000) .expireAfterWrite(Duration.ofMinutes(5)) .refreshAfterWrite(Duration.ofMinutes(1)) .recordStats() .build(); } }

逐个说下参数：

maximumSize是条数上限，不是内存上限，这是一个特别容易踩的认知偏差。预估内存用公式：单条对象平均大小（字节）乘以最大条数，再除以1024再除以1024得到MB。假设商品详情对象序列化后平均2KB，2万条就是40MB左右，对一个8G堆的实例来说完全可接受；但如果单条对象是几十KB，同一个值就可能吃进几百MB堆内存。所以配置这个参数之前，建议先抽几个真实对象量一下大小。

2.3 多级缓存里Caffeine该怎么加载

这里要说一个和官方文档不太一样的地方。Caffeine提供了get(key, loader)这种带加载逻辑的读法，但在多级缓存架构里，我建议不要把Caffeine的loader作为读取入口。原因很简单：loader只负责回填Caffeine自身，你还需要回填Redis，这个流程自己控制才可控。

标准的读取流程我在代码里拆开写：

public Product getProduct(String id) { // 第一层：本地缓存 Product p = localCache.getIfPresent(id); if (p != null) { return p; } // 第二层：Redis，miss后再走数据库 p = loadFromRedisOrDb(id); if (p != null) { localCache.put(id, p); } return p; }

loadFromRedisOrDb内部就是先查Redis，查不到再查数据库，查到后把结果写回Redis并设置TTL。第二层和第一层的写入时机分开处理，这样每一层的过期策略、空值处理、异常兜底都能单独做，不会纠缠在一起。

2.4 本地缓存最容易踩的四个坑

坑一：refreshAfterWrite的默认线程池是ForkJoinPool.commonPool。一旦刷新逻辑里执行了较重的DB查询，整个公共线程池都会被拖慢，其他所有用到commonPool的并行任务跟着遭殃。刷新线程池一定要自己定义。

ExecutorService refreshExecutor = new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000), r -> new Thread(r, "caffeine-refresh-worker")); Caffeine.newBuilder() .refreshAfterWrite(Duration.ofMinutes(1)) .executor(refreshExecutor) .build();

坑二：maximumSize只限制条数，不限制内存。如果缓存对象内部还引用了大数组、大字符串，GC压力会很明显。我遇到过商品详情里有图片地址列表和完整描述文本，单个对象序列化后超过5KB，数量一上来，Young GC频率肉眼可见地上升。处理办法是缓存前做字段裁剪，只保留接口真正需要的数据。

坑三：value对象被业务代码意外修改。有的同学把数据库拿到的实体直接丢进缓存，外面拿到的引用改了一个字段，缓存里的数据也跟着变了，最终和数据库产生脏数据。放进缓存的对象，要么是不可变的只读DTO，要么放进去之前做一次深拷贝。

坑四：应用重启后本地缓存全部清空，瞬间的miss流量全部打到Redis。发布一次，Redis的QPS就尖峰一次。解法是在应用启动时做预热，把过去一段时间访问量最高的N个key预先加载回Caffeine。

这些坑单看都不致命，但叠加在一起，足以让一个配置不合理的本地缓存层从优化手段变成事故源头。

3. Redis层：序列化、连接池与Key规范

3.1 序列化方案不能乱选

Redis的值要经过序列化才能存进去，序列化方案直接决定了网络传输的体积、可读性和跨语言兼容性。

Spring Boot里默认的序列化器在不同版本里不统一，建议显式配置。我自己的偏好是内部服务用Jackson，指定好具体类型，省掉@class类型信息，既减小体积又避免反序列化安全风险。至于JDK原生序列化，它在对象结构变化时兼容性差、字节流里塞了一堆类元数据，除了图省事没有任何优点，第一次压测就会露出原形。

3.2 连接池参数别照抄网上模板

Redis连接池的配置，网上能搜到一堆模板，但大多是“看起来合理”的参数，不结合自己系统的QPS和延迟去算，抄了反而出事。一个稳妥的起点如下：

spring: redis: timeout: 200ms lettuce: pool: max-active: 16 max-idle: 8 min-idle: 4 max-wait: 300ms

max-active不是越大越好。每个连接都要占一个文件描述符，连接数过高时，突发流量下建立连接本身就会成为风暴，甚至把Redis端的CPU先打上去。在多级缓存架构里，Redis连接池的担子已经轻了很多，本地缓存命中率90%的情况下，每秒到Redis的请求可能只有一千多，16个连接完全够用。

还有一个容易忽略的点：timeout设置的是连接超时还是读写超时，不同版本含义不同，建议压测时专门构造一次Redis端故障，看应用的等待行为是否符合预期。

3.3 Key设计与TTL策略

Redis的Key设计看起来基础，实际是线上事故的重灾区。统一的格式建议用：业务域:模块:实体:ID，比如pms:product:detail:1001。这样做的好处是排查问题时可以用SCAN按前缀过滤，也可以按模块维度做批量治理。

TTL设计上，基础数据可以给10到30分钟，频繁变更的数据给1到5分钟。这里有一个多层缓存之间容易忽略的细节：本地缓存的过期时间应该短于Redis，比如Caffeine 5分钟、Redis 30分钟。这样即使Redis里还有数据，本地缓存也能较快感知到数据可能变化，避免两层缓存都长时间持有旧值。

防雪崩的TTL抖动也要做，这个放到后面第五部分详细说。

3.4 大Value与热点Key在Redis层的处理

Redis对大Value不友好。单个Value超过几百KB甚至几MB时，每次读取的网络传输成本直线上升，持久化时也会拖慢AOF重写和RDB快照。商品详情里如果有长文本或列表，建议压缩存储，或者干脆拆分成多个小Key，按需读取。我在压测里见过单Key超过500KB的情况，流量一起来，Redis节点的网卡首先被打满。

热点Key在Redis层的检测手段其实不多，比较务实的做法是在应用侧记录每个Key的访问频率，把超过阈值的Key名单同步到本地缓存层加长TTL。这部分逻辑放在第五部分细说。

4. 两级缓存的一致性：更新顺序与失效链路

4.1 为什么主流做法是“先更新数据库，再删缓存”

多级缓存的数据更新，业界主流是Cache Aside模式：更新数据库，然后删除缓存，而不是更新缓存。为什么删而不是更新？因为更新缓存要求你回写的值一定正确，一旦并发场景下回写顺序错乱，脏数据就一直留在缓存里；而删除缓存最多造成一次缓存miss，下次读请求会重新从数据库加载，自愈能力强得多。

顺序上为什么先更新数据库再删缓存？如果先删缓存再更新数据库，在“删除缓存”和“更新数据库”这个时间窗口内，任何一个读请求都会把旧值重新写回缓存，等数据库更新完，缓存里已经留下了永久的旧数据，这个脏窗口比先写库再删缓存要大得多。所以标准做法永远是先写库、再删缓存。

4.2 并发写回旧值的坑与延迟双删

先写库再删缓存也不是绝对安全。有一个经典并发竞争：线程A读缓存miss，然后去数据库读到了旧值；在线程A把旧值写回缓存之前，线程B完成了数据库更新并删除了缓存；线程A随后把旧值写回了缓存。结果缓存里留下旧值，直到下一次过期才恢复。

延迟双删就是针对这个场景的补丁方案：更新数据库后删除一次缓存，过几百毫秒再删一次。第一次删除能清掉大部分旧值，第二次删除覆盖的是那些恰好卡在时间窗口里的“迟到写回”。

public void updateProduct(Product product) { db.update(product); String redisKey = buildKey(product.getId()); redisTemplate.delete(redisKey); localCache.invalidate(product.getId()); // 延迟删除，处理并发读请求把旧值写回的边界情况 cacheExecutor.schedule(() -> { redisTemplate.delete(redisKey); localCache.invalidate(product.getId()); }, 500, TimeUnit.MILLISECONDS); }

要直说一句：延迟双删本质是概率性方案，延迟时间不好确定，只能覆盖大多数生产场景，不是严谨的一致性保证。如果业务对一致性要求极高，需要另上版本号方案或者用消息队列做最终一致性，延迟双删作为兜底才有意义。

4.3 多实例本地缓存怎么同时失效

这是多级缓存最容易翻车的一个点。同一个商品数据在每个服务实例的Caffeine里都有一份，你更新数据库后只删了自己实例的本地缓存，其他几个实例的缓存还在，用户请求如果负载均衡到了其他实例，读到的依然是旧值。

解决办法是让“缓存失效”这件事广播给所有实例。最可靠的路子是走MQ：更新数据库后发一条失效消息，所有服务实例消费消息后删自己本地的key。

// 更新服务 public void updateProduct(Product product) { db.update(product); redisTemplate.delete(buildKey(product.getId())); mqTemplate.convertAndSend("cache.invalidate", product.getId()); } // 每个实例的消费端 @RabbitListener(queues = "cache.invalidate") public void onCacheInvalidate(String id) { localCache.invalidate(id); }

如果不想引入MQ，有人会考虑Redis的Pub/Sub。我的建议是生产环境别用：Pub/Sub是即发即弃的，消费者不在线或者消费失败，消息就丢了，本地缓存会一直脏下去。MQ虽然重了一点，但消息会持久化，消费失败还能重试，最终一致性才是真的能落地。

4.4 一致性窗口的量化与取舍

把一致性窗口量化出来，才能判断方案够不够用。单实例上，“先写库再删缓存”的不一致窗口只有从删Redis到删本地缓存之间的毫秒级时间；跨实例情况下，收到MQ消息之前的窗口取决于消息生产和消费延迟，通常也就几十到几百毫秒。对绝大多数读多写少的业务，这个短暂旧值是可以接受的。

多级缓存的本质是在性能和一致性之间做交换。你不能让缓存层既提供毫秒级响应，又保证和数据库强一致。改造前先和业务确认清楚：这个数据允许最多多少秒的延迟？如果答案是零，那这个数据不应该进缓存系统。

5. 缓存穿透、击穿、雪崩：三兄弟逐个拆解

5.1 穿透：空值缓存与布隆过滤器

缓存穿透是请求了一个根本不存在的数据，所有缓存层全部miss，请求直接打到数据库。攻击者如果拿一堆不存在的ID循环请求，数据库会被拖垮。

第一道防线是空值缓存：查不到数据时，在Redis和Caffeine里存一个空值占位，TTL给30到60秒。代码上要区分“缓存里没有”和“业务数据不存在”两种情况，空值缓存命中时直接返回空对象，不走数据库。

第二道防线是布隆过滤器。读取前先判断这个ID是否可能存在，如果过滤器说“不存在”，直接返回，连缓存都不用查。布隆过滤器的好处是空间极小，代价是存在误判，但它的误判方向是“把不存在的ID放过去”，不会把真实数据挡掉，所以在缓存系统里很合适。要注意的点是：新增合法ID之后，布隆过滤器不会自动把这个ID加进去，需要定期重建或者对新增ID做豁免处理。

5.2 击穿：锁的粒度与双重检查

缓存击穿是某个热点key在过期的一瞬间，大量并发请求同时miss，一起打到数据库。防护思路是互斥：同一时刻只允许一个线程去查库回填，其他线程等回填完成后直接读缓存。

我之前用的是本地锁加双重检查，代码骨架如下：

private final ConcurrentHashMap<String, Object> lockMap = new ConcurrentHashMap<>(); public Product getProduct(String id) { // 第一层 Product p = localCache.getIfPresent(id); if (p != null) return p; // 第二层 String redisKey = "pms:product:detail:" + id; Product cached = redisTemplate.opsForValue().get(redisKey); if (cached != null) { localCache.put(id, cached); return cached; } // 只让一个线程查库 Object lock = lockMap.computeIfAbsent(id, k -> new Object()); synchronized (lock) { // 二次检查，避免重复查库 p = localCache.getIfPresent(id); if (p != null) return p; cached = redisTemplate.opsForValue().get(redisKey); if (cached != null) { localCache.put(id, cached); return cached; } p = queryDb(id); if (p != null) { redisTemplate.opsForValue().set(redisKey, p, Duration.ofMinutes(30)); localCache.put(id, p); } return p; } }

两个细节提醒：一是lockMap会随着新id的访问一直膨胀，要定期清理无用的锁对象，否则又是一块内存泄漏；或者直接用固定条数的分段锁，比如按id.hashCode() % 16分到16把锁，用一点并发冲突换内存安全。

二是这个方案锁的是本实例，如果六个实例同时miss，数据库还是会收到最多六份查询。对数据库来说这个量级可以接受，如果你连这个都不想让步，再上分布式锁，但代价是每次击穿防护多一次Redis RTT，是否值得要掂量着来。

5.3 雪崩：让失效时间错开

雪崩是大批key在同一时间过期，所有读请求同一瞬间穿透到数据库。最直接的手段是失效时间加随机抖动：在基础TTL上加减一个随机值，让同一批缓存的过期时间错开。

Redis的TTL要抖动，Caffeine的过期时间也要抖动。很多同学只给Redis加了抖动，忽略了本地缓存这层，结果服务启动后同一时间加载的热点数据，在同一时间在每台机器上过期，照样造成压力尖峰。两层缓存的TTL都做随机化，才能真正把雪崩的概率降下来。

除此之外，Redis本身要有高可用方案，不能是单点，集群和哨兵至少上一个。缓存层挂了，后面的数据库就是裸奔。

5.4 热点key动态识别：把保护前置

固定参数的防护只能处理预设问题，生产环境里热点key是动态的，活动开始后某件商品突然爆火，你不可能提前知道它叫什么。比较实用的做法是在应用侧加一个轻量计数：每个id每次读缓存命中时计数器加一，超过阈值就把这个id的热点状态置为true，然后把这个key的本地缓存TTL从5分钟临时延长到30分钟，同时把Redis的TTL也一起延长。

优势在于热点key在缓存里待的时间更长，被淘汰的概率更低，Redis侧的集中流量自然而然就下来了。注意这个计数器本身要控制数量，定期清理掉不再热的数据，别让“热点识别”自己变成另一个内存问题。

6. 压测数据与调优记录：多级缓存的真实收益

6.1 压测场景与结果

压测环境是四实例应用，8核16G，模拟商品详情读接口，只读不写。三个方案的对比结果如下：

所有数字是我自己测试环境里的典型值，不代表任何基准测试。能看到的关键转折是：加了本地缓存后，Redis的QPS从9600掉到了1500，数据库的QPS从380掉到了35。这个DB QPS的下降幅度对数据库来说才是真正的保护，缓存的价值从来不只是快，而是给下游留出余量。

6.2 压测暴露的四个问题

第一个问题：本地命中率一开始只有60%左右，查了半天发现是maximumSize设成了1000，而商品池子里有几十万个ID，热点数据频繁被新数据挤出去。把maximumSize调到2万后，命中率稳定在92%以上。

第二个问题：服务重启后Redis QPS瞬间翻倍。原因是没有预热机制，Caffeine冷启动后所有读请求全部穿过Redis。后来在启动流程里加了Top N热点key预热，发布窗口的Redis QPS尖峰降了70%。

第三个问题：refreshAfterWrite的异步刷新期间，ForkJoinPool.commonPool被DB查询拖住，压测过程中出现线程阻塞型告警。换用自定义线程池之后问题消失。

第四个问题：部分商品详情序列化后超过500KB，Redis读多后网卡告警。最后对字段做了瘦身，大字段改成延迟加载，单Key体积控制在50KB以内，网卡指标明显回落。

6.3 上线后要盯的指标

多级缓存上线后，下面几个指标要放进监控看板。

Caffeine的命中率可以直接拿到，代码里配了recordStats()之后：

CacheStats stats = localCache.stats(); double hitRate = stats.hitRate(); long evictionCount = stats.evictionCount();

本地缓存命中率低于70%，基本说明配置有问题，要么maximumSize太小，要么热点key没有被正确识别。Redis侧要看QPS和网卡带宽，这两个指标代表了缓存层回源的压力。数据库侧要看读QPS，正常回源率应该很低。GC频率也要盯，本地缓存使用不当会让堆内存压力直接反应到GC上。

6.4 什么情况该反向取舍

多级缓存不是越多越好，也存在该砍掉一级缓的场景。如果业务数据更新极其频繁，比如每秒钟都有人在改同一个商品，本地缓存缓存十几秒旧值的收益会被“每次更新要广播失效消息”的成本抵消。另一些场景对一致性要求到毫秒级别，本地缓存根本没法满足，这种情况宁可把缓存降级为只做Redis，或者干脆只做查询缓存。

设计多级缓存时，先把业务对实时性的容忍度问清楚，再决定每一层的TTL和一致性方案，顺序反过来会吃大亏。

最后说点个人体会。我在多级缓存上踩过的坑，一半是参数配置不合适，另一半是上线的监控没跟上。参数的问题靠压测能暴露，监控的问题靠报警能兜住。一个小技巧分享给大家：上线前把每个缓存key的TTL、缓存层数、淘汰策略、失效方式列成一张清单，压测时逐项验证。我见过不少线上事故，起因都是某个缓存key的TTL被顺手写成永不过期，数据越堆越多，最后连Redis持久化文件都膨胀到几十GB。缓存架构做得再漂亮，也抵不过一个失控的Key。

这套Caffeine加Redis的架构，适合的是读多写少、单条数据体量可控、业务能容忍秒级不一致的场景。如果你的系统正好符合这几个条件，照着上面的配置和流程改造一遍，压测数据大概率会让你满意。