作为一个常年跟缓存打交道的后端开发多级缓存这个方案我前后在不同项目里折腾过好几轮从最开始的Redis单打独斗到后面扛不住流量把Caffeine加进来踩了不少坑也沉淀了不少经验。今天这篇就把SpringBoot Caffeine Redis这套多级缓存的完整实现思路、核心代码、参数调优和排坑记录一次性整理出来希望能帮到正在做缓存设计或者被缓存击穿搞得头疼的朋友。先从问题说起。大部分业务系统最开始用Redis做缓存简单直接撑个几百上千的QPS问题不大。但等流量上来或者遇到热点key集中访问时Redis的网络IO和序列化开销就会成为瓶颈。尤其是那种单key每秒几万次读的业务哪怕Redis再快一次网络往返下来耗时和带宽压力都很明显。我见过有的团队为了让Redis抗住热点把过期时间越调越短结果又引发缓存击穿DB直接被冲垮。这套方案的核心思路很简单把缓存分成两层热数据放本地全量数据放远端先查本地再查远端本地没有才走网络。本地缓存用Caffeine基于进程内存纳秒级访问零网络开销Redis负责多实例共享数据承担回源数据库的压力。两层配合既能扛高并发又能保证数据在多节点间基本一致。这套方案适合谁来参考如果你正在做SpringBoot项目业务上有明显的读多写少场景比如商品详情、用户信息、配置数据或者你的服务已经部署了多实例Redis的QPS和带宽快吃满那么这个方案可以直接抄作业。如果你的项目还是单机部署、并发量不高我建议先别急着上多级缓存Redis单层足够多级反而增加一致性和运维复杂度。1. 方案选型为什么是Caffeine Redis而不是别的组合先聊选型。本地缓存的选项其实不少老牌的Guava Cache、Ehcache新兴的Caffeine还有简单粗暴的ConcurrentHashMap。我并不是说其他的不行但各有使用场景。ConcurrentHashMap适合纯本地小数据量的读写缺淘汰策略没内存控制容易OOMGuava Cache功能完整但性能不如Caffeine尤其是高并发读写场景下差距明显Ehcache算是老将偏向于需要落盘、堆外缓存等重量级需求在SpringBoot生态里配置偏重。Caffeine是受Guava启发重写的本地缓存库在内存管理、淘汰算法、并发控制上都做得更极致也是目前Spring Boot默认支持的本地缓存方案之一。它基于W-TinyLFU淘汰算法维护一个频率布隆过滤器和两个LRU窗口既能识别热点数据长期保留又能让低频数据快速让位实测下来本地缓存的命中率比Guava要高不少。再聊Redis这层的定位。Redis负责的是跨节点的全局缓存。多实例部署的时候A节点的本地缓存和B节点是各自独立的如果数据只在Caffeine里用户请求落到B节点就查不到所以需要一个共享层兜底。Redis作为共享层核心作用不是抗所有请求而是做数据回源和一致性锚点。换句话说热点数据尽量在Caffeine层消化Redis承受的请求越少整体延迟和带宽压力越低。从技术生态的角度看Caffeine有Spring Boot官方starter适配Redis有Spring Data Redis支持两个都跟SpringBoot配合得很好引入成本很低。我最早也考虑过把Redis换成内存数据库或者直接上CDN但对大多数业务系统来说太重了而且Redis在持久化、过期策略、集群方案上已经足够成熟。本地缓存 分布式缓存是目前性价比最高、最容易被团队接受的多级缓存组合。选型上还有一个容易忽略的点Caffeine是单机缓存每次服务重启、发布时必然全部清空如果直接把Caffeine当作数据的主缓存层会在发布瞬间给Redis带来一波穿透流量。Redis虽然比DB能扛但上千个key同时回源也不是小压力。所以必须给Redis设置合理的过期时间和空值缓存策略把穿透压力挡在DB之外这点我会在后面排坑部分详细说。2. 核心流程设计两级缓存怎么配合工作多级缓存的设计核心是读流程和写流程。先说读流程这个最直观。2.1 读缓存流程先本地再Redis再DB逐级回填一次读请求进来顺序是这样的查Caffeine如果命中直接返回请求结果这个阶段没有任何网络IO性能接近直接读内存。Caffeine未命中查Redis如果命中把数据回填到Caffeine然后返回结果。Redis也未命中查数据库拿到数据后依次回填Redis和Caffeine然后返回结果。这个流程在代码层面就是一层一层的if判断。有个细节我最早没注意结果导致Caffeine没起到缓存作用回填Caffeine的时候一定要把从Redis拿到的数据先反序列化成对象再放入本地缓存而不是把Redis的原始JSON字符串直接放进去。否则每次从Caffeine取出的都是同一个字符串对象业务层还得重复解析性能优势损耗大半。再一个细节是并发的控制。缓存未命中时如果上百个线程同时查到同一个key全部回源DB就会产生缓存击穿。Redis层可以借助分布式锁来保证单线程回源Caffeine层有现成的get(key, mappingFunction)方法能保证单个key只有一个线程执行加载逻辑其他的等待结果返回。多级缓存的每层都要有这层并发保护否则上层缓存恢复的速度赶不上穿透的速度DB还是会被冲垮。读流程的代码骨架看起来不复杂真正复杂的是数据回填时的过期时间策略。热点数据回填到Caffeine可以用相对较短的过期时间比如几分钟到十几分钟因为本地缓存更新快、粒度小Redis的过期时间建议设置得长一些因为Redis的数据要被所有实例共享而且多实例场景下Caffeine过期后还能回到Redis查Redis这层能撑多久直接决定了DB能休息多久。2.2 写缓存流程先写DB再删缓存两级都要管写流程比读流程更容易出问题。最简单的缓存更新策略有三种先更新DB再更新缓存、先删缓存再更新DB、先更新DB再删缓存。我直接说结论主流方案是先更新数据库再删除缓存也就是经典的Cache Aside模式。原因是更新和删除相比更新缓存在并发写场景下容易出现过期数据覆盖新数据的问题而删除缓存即使删慢了一点最多就是多一次缓存穿透数据正确性影响小。删除的时候需要同时删Redis和Caffeine但Caffeine删除只能删除当前节点其他节点的Caffeine还会保留一段时间的老数据所以对一致性的要求不能定得太高。有一种情况要特别小心更新DB成功后删除Redis失败就会导致DB和Redis数据不一致。解决方案有两个方向。第一个是引入可靠消息重试把删除消息发到队列异步消费重试第二个是采用延迟双删先删除缓存再更新DB隔一段时间再删除一次缓存。这两种方案我在生产环境都试过消息重试适合数据变更频繁、失败容忍度低的场景实现起来稍微啰嗦一点延迟双删实现简单但双删的时间间隔不好把握太短会删除过早太长会放大数据不一致窗口。从实际经验看大多数业务系统对数据一致性的容忍窗口在几百毫秒到几秒之间延迟双删配合短TTL已经够用。如果业务方对一致性要求极高比如库存、资金这类就不建议用缓存或者最多用很短的TTL兜底否则一致性设计会让你陷入无尽的复杂度里。2.3 缓存过期策略本地短过期、远端长过期过期时间的设计是多级缓存最容易忽略但影响最大的细节。如果Caffeine和Redis都设置同样的过期时间会出现一个尴尬的现象Caffeine在某个key过期后的同一时间点大量请求同时穿透到RedisRedis全部未命中后同时回源DB刚好形成了一次集中穿透。所以最好给两层缓存设置不同的过期时间并且给同一层内的key设置随机偏移把击穿的时间点打散。我一般在项目里这么定Caffeine过期时间3到10分钟根据业务实时性要求灵活调整偏向短一些。Redis过期时间30到60分钟偏向长一些。Redis的TTL在写入时加上随机值偏移范围是基础值的1到5分钟。为什么要这么设计本地缓存过期了还能去Redis查Redis兜底时间越长DB被查询的频率就越低。而Redis过期时间分散后就算Caffeine短时间内全部失效也不会同时穿透同一个key。至于那些跨节点的一致性需求因为Caffeine过期时间足够短最迟几分钟内所有节点最终能拿到新数据。3. 项目实操SpringBoot代码实现与参数配置开始写代码之前先把依赖和基础环境准备好。这个项目沿用了我在生产环境里的标准配置SpringBoot 2.7.x Caffeine 2.9.x Redis 6.x。3.1 引入依赖与基础配置在pom.xml里加三个关键的依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencySpring Cache的抽象层主要用来管理缓存的注解和声明式缓存策略。但如果只是为了做多级缓存完全没必要用Cacheable注解硬套因为注解方式的缓存管理粒度不够细两级缓存的顺序控制也不够直观。这里我直接封装了一个缓存工具类手动控制读取和回填流程比注解更可控。然后是application.yml里Redis和Caffeine的基础配置。Redis要配置连接池连接池参数直接影响高并发下Redis的稳定性。Caffeine部分用CacheString, Object手动构建配置写在Java类里更清晰。spring: redis: host: 127.0.0.1 port: 6379 timeout: 2000ms lettuce: pool: max-active: 100 max-idle: 50 min-idle: 10 max-wait: 500msRedis连接池的线程模型特别值得多说一句。Spring Boot 2.x默认使用Lettuce连接池Lettuce本身是异步客户端线程安全连接可以复用。但max-active不要盲目调大。我曾经在一台8核16G的机器上把max-active调到200结果Redis没挂应用先频繁Full GC因为连接的缓冲区和监听器对象全是内存开销。正常情况下单实例Redismax-active在50到100之间足够用。3.2 Caffeine缓存配置类Caffeine的配置可以直接写在配置类里通过一个CacheString, Object实例来管理。字段定义很简单但这个配置的每一行都值得推敲。Configuration public class CacheConfig { Bean(localCache) public CacheString, Object localCache() { return Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() .build(); } }maximumSize决定本地缓存的条目上限。这个值一旦设置不合理要么内存浪费要么缓存频繁被淘汰导致命中率低于预期。我通常的估算方式是按业务key数量乘上平均对象大小。比如一个商品详情对象序列化后大概5KB缓存1万个key内存占用差不多50MB对于动辄几G堆内存的应用来说完全能接受。但如果你缓存的对象里有大字符串或者嵌套集合就得按10倍甚至更大的余量去评估。expireAfterWrite(5, TimeUnit.MINUTES)是写入后5分钟过期。这里没有用expireAfterAccess因为后者在热点数据的持续访问下可能永远不过期容易让数据长期处于陈旧状态。实时性要求高的数据先用expireAfterWrite让缓存数据有固定的更新节奏。recordStats()官方的说法是开启命中率统计实际用的时候这个开关影响很小但能让我们在监控里看到Caffeine的命中率、加载次数和淘汰数量。生产环境中我是直接把CacheStats定时打到监控面板这样能直观判断缓存层是否在正常工作。3.3 多级缓存操作类封装接下来是核心代码。整体思路不绕弯子一个方法实现读缓存逻辑另一个方法实现写缓存逻辑缓存值统一用JSON字符串存储。Component public class CacheManager { private static final JsonUtil JSON new JsonUtil(); private static final String CACHE_PREFIX biz:cache:; Resource private CacheString, Object localCache; Resource private RedisTemplateString, Object redisTemplate; /** * 读取缓存 * 顺序本地 - Redis - DB */ public T T get(String key, ClassT clazz, CacheLoaderT loader) { // 1. 本地缓存 Object cacheValue localCache.getIfPresent(key); if (cacheValue ! null) { return (T) cacheValue; } // 2. Redis缓存 String redisKey CACHE_PREFIX key; Object redisValue redisTemplate.opsForValue().get(redisKey); if (redisValue ! null) { T value JSON.parseObj(redisValue.toString(), clazz); // 回填本地缓存 localCache.put(key, value); return value; } // 3. 数据库加载 T value loader.load(); if (value null) { // 空值缓存防止缓存穿透 redisTemplate.opsForValue().set(redisKey, , 300 randomTimeOffset(), TimeUnit.SECONDS); localCache.put(key, null, Duration.ofSeconds(300)); return null; } // 4. 回填Redis与本地 redisTemplate.opsForValue().set(redisKey, JSON.toJsonStr(value), expireTime randomTimeOffset(), TimeUnit.SECONDS); localCache.put(key, value); return value; } /** * 更新缓存 * 先更新DB再删缓存 */ public void update(String key, Object dbData) { // 这里由调用方先完成DB update然后调用本方法 String redisKey CACHE_PREFIX key; redisTemplate.delete(redisKey); localCache.invalidate(key); } private long randomTimeOffset() { return ThreadLocalRandom.current().nextLong(60, 300); } }我特别解释一下空值缓存。第一次写这套缓存时发现某个key在DB里查不到业务上还是会以高频的方式重复查询于是每次查询都直接打到DB上这就是典型的缓存穿透。空值缓存就是在Redis和Caffeine里都给“查不到”的结果放一个占位符并给一个极短的过期时间。这样DB不会被无意义的查询打爆又保证数据一旦写入很快能被读到。Redis那边为了区分正常值和空值我的做法是统一用空字符串占位读取时如果值是空字符串直接返回null就不再向下穿透。另外要注意loader.load()这段的并发控制。上面代码看起来简单但多个线程同时发现本地缓存没有、Redis也没有时依然会同时调用loader.load()回源数据库这不是多级缓存该有的表现。实际项目中需要给Redis那段加分布式锁Java实现一般用Redis的SET key value NX EX命令或者Redisson框架保证同一时刻只有一个线程回源数据库其余线程等待锁释放后再重新查缓存。Caffeine的get(key, mappingFunction)虽然能保证本地单key只加载一次但Redis那层没有这个语义。3.4 Redis序列化配置RedisTemplate默认使用JDK序列化存进去的内容是一堆二进制不仅体积大而且没法直观地排查问题。必须自定义序列化方案生产环境我是用GenericJackson2JsonRedisSerializer。Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // 使用GenericJackson2JsonRedisSerializer GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(serializer); template.setValueSerializer(serializer); template.setHashKeySerializer(serializer); template.setHashValueSerializer(serializer); template.afterPropertiesSet(); return template; } }这里有个坑GenericJackson2JsonRedisSerializer在反序列化时会携带class类型信息如果缓存的POJO类发生了字段变更可能直接反序列化失败。我曾经遇到过一个字段被重命名旧缓存里的JSON还带着旧字段新代码反序列化时因为class指向的错误字段直接抛异常。后来我改用自定义序列化对象手动存储JSON字符串不用RedisTemplate默认的对象转换然后把反序列化工作交给业务层最大程度避免类型绑定的强耦合。上面工具类里用的就是这种思路。4. 方案细化多级缓存的性能对比压测光说不练等于白搭。我在一个模拟项目X里搭了一套完整的多级缓存环境数据库用MySQLRedis单机服务单实例。压测工具用的是wrk压测场景是模拟商品详情的读请求key数量固定5000个并发线程50持续压测5分钟。先看测试对比数据方案平均响应时间(ms)99分位响应时间(ms)实际QPS命中率说明无缓存直连DB28.462.1约1800无命中Redis单层缓存6.815.3约7600Redis命中率约99%CaffeineRedis多级缓存1.64.2约15000Caffeine命中率约88%注意这里Caffeine的命中率88%说明大约88%的请求走到了本地内存只有12%经过网络访问Redis。Redis层的QPS大概在1800左右远比单层Redis方案的7600低。网络IO的节省是响应时间大幅下降的核心原因。Redis单层虽然平均6.8ms但在高并发下受限于网络带宽和连接池复用延迟波动会明显上升。多级缓存把87%以上的请求挡在本地后Redis的压力骤降网络抖动的影响也被隔离了。我压测时发现一个有意思的细节如果压测前把Caffeine的maximumSize调大或者调小命中率变化非常大。5000个key的测试场景maximumSize设置5000时Caffeine命中率达到88%如果再降一倍到2500命中率直接掉到70%响应时间立刻上涨。这个现象给后来的参数调优提了个醒本地缓存的容量不能拍脑袋定最好能根据业务的key规模来动态推算留足余量。再看一个我特意测过的场景全缓存失效瞬间的表现。压测前把所有缓存清空同时发起满负荷请求观察这几个方案的DB压力场景DB高峰QPS高峰持续时间响应时间抖动Redis单层无锁约1800持续至缓存重建p99飙升至800msRedis单层互斥锁约300约3秒p99轻微上升多级缓存互斥锁约150约0.8秒p99轻微上升多级缓存在缓存全清后恢复最快因为Caffeine本身重建极快Redis的回源由分布式锁限流DB根本感知不到大流量。这也是多级缓存在高并发系统里最有价值的地方。5. 坑点解析与排查经验缓存穿透、击穿与雪崩多级缓存不是加上就完事了里面暗藏的风险很多这部分全部来自我真实踩坑后的复盘。5.1 缓存穿透查不到的数据也要缓存穿透是指请求查找一个DB里也不存在的数据缓存层永远没命中所有请求都打到DB。这是最容易被忽略的场景。有些开发觉得“查不到说明无数据缓存里存null也没什么用”但他们没想明白攻击者或者异常用户可以用大量不存在的ID高频请求流量全打在DB上DB会被拖垮。解决方案我在代码里已经给出了空值缓存。哪怕查询结果是null也把它放进缓存里并设置短TTL比如30秒到5分钟。这样同一个无效key的第二次查询开始就能挡住。数据库层面的兜底方案是布隆过滤器把存在的ID提前加载到布隆过滤器里请求来了先判断ID是否存在不存在直接返回但这个方案维护成本高而且布隆过滤器更新和业务写入的一致性不太好处理我没上。5.2 缓存击穿热点key必须加锁击穿是指某个热点key的缓存到了过期时间刚好在这个时间点有大量请求访问缓存未命中导致所有请求同时穿透到DB。多级缓存结构里Caffeine和Redis任意一层的过期都可能导致下一层被穿透。解决办法有两个层次。Caffeine层用Cache.get(key, mappingFunction)它能保证同一个key只有一个线程执行加载逻辑其他线程等待结果但要注意mappingFunction执行期间其他线程是阻塞的如果加载DB特别慢请求会排队积压。Redis层加分布式锁参考代码里读缓存流程那段要用setIfAbsent拿锁拿锁成功的线程去DB查询并回填缓存等锁失败的线程休眠一小段时间后重新查缓存。我习惯用Redisson的RLock它的waitTime和leaseTime可以控制最长等待和锁自动释放避免死锁。5.3 缓存雪崩大批key同时过期雪崩是指大量缓存在同一时间过期导致请求全部回源DB。多级缓存天然对雪崩有缓解作用因为Caffeine和Redis的过期时间是错开的Caffeine没过期前Redis的过期影响不大。但Caffeine如果全量清空呢比如服务发布重启这个场景实际上很常见。每次重启本地缓存全部消失瞬间所有请求都打到Redis如果Redis再来一次大规模过期DB瞬间压力爆炸。我使用的方案是多层缓冲Redis的TTL制定时增加随机偏移比如60分钟加1到5分钟的随机数避免同一时刻大规模过期。对热点key设置永久缓存或绝长TTL配合后台定时刷新任务避免缓存自然过期。服务重启时先触发一次缓存预热把热点数据提前加载到Caffeine让刚启动的实例不至于空缓存接流量。这三板斧叠加下来缓存雪崩基本被挡在可控范围内。5.4 数据一致性删缓存失败怎么兜底前面提到过先更新DB再删除缓存的方案。但删除Redis缓存可能失败一旦失败数据就会在TTL内不一致。这个问题在生产环境出现的概率不低尤其是网络抖动、Redis连接池满了的时候。我的兜底方案比较简单直接借助Spring的定时任务做增量扫描把删除失败的key重新清一遍。具体说更新DB成功后往本地一个延迟队列塞一条记录记录里带着缓存key和期望删除时间后台线程每隔5秒扫描延迟队列到期后统一执行Redis删除如果删除后再次失败记录会重试最多3次。这个方案实现成本低不依赖消息中间件对大多数场景够用了。延迟双删方案我也用过实现更简单但需要根据业务经验估算延迟时间。如果数据库主从同步耗时超过预期双删的时间点就会失效。所以我现在更倾向于延迟队列 失败重试理由是可控性和可观测性更强。5.5 多实例一致性本地缓存更新通知前面聊的缓存更新默认都是单实例视角。生产环境肯定是多实例部署A节点更新了DB并删除了自己Caffeine里的缓存但B节点Cafffeine里的旧数据还留着。这时候有两种选择。一种是接收“本地缓存失效”的广播消息。有了Redis的Pub/Sub或者消息队列A节点删除缓存时发一条通知其他节点收到后也删除自己的本地缓存。这个方案能做到秒级一致但会引入新的中间件依赖和消息丢失风险架构复杂度明显提升。另一种是接受短暂不一致靠Caffeine的短TTL兜底。我在项目里的选择是实时性要求一般的场景用TTL兜底实时性要求较高的独立接口直接绕过本地缓存只走Redis。6. 可观测性建设缓存统计与监控多级缓存做出来后没有监控等于白做。缓存命中率、耗时、容量这些数据必须能看得见否则你根本不知道参数要不要调整。Caffeine自带recordStats()可以通过localCache.stats()拿到hitCount、missCount、evictionCount等指标。我一般直接把CacheStats里的数据封装成指标定时上报到监控大盘。Redis那层的监控相对简单用Spring Data Redis的get和set统计耗时或者直接依赖Redis的INFO命令看内存和连接数。最有价值的指标是两级缓存的命中率变化趋势。如果发现Caffeine命中率持续走低大概率是maximumSize设置太小或者expireAfterWrite太短如果Redis命中率持续走低异常排查方向则是Redis过期时间、数据写入逻辑和缓存预热是否正常。还有一个容易被忽略的监控维度Caffeine的淘汰数量。当淘汰数量暴涨时说明缓存容量已经接近上限热点key在被频繁挤掉这时候就算命中率还没明显变化也要开始扩容或调参了。我的监控指标存到某个时序数据库里用仪表盘可视化。核心指标包括Caffeine命中率、淘汰数、加载数Redis读取耗时、写耗时、连接池活跃连接数DB回源QPS两级缓存的平均过期时间这几项指标加在一起基本能定位90%以上的缓存问题。7. 写在经验之后从单层Redis到多级缓存我最大的体会是整条链路的瓶颈会一直在移动。你解决了Redis的高负载新的瓶颈可能就出现在本地缓存的容量或者GC上你优化了Caffeine的过期策略新的问题可能藏在序列化和反序列化里。多级缓存不是把两个缓存叠起来就完了每一环节都必须配上监控和数据反馈来支撑决策。一个小技巧分享给你如果你不想一开始就把多级缓存铺到所有接口可以先挑几个热点接口加Caffeine让监控跑一周对比Redis的QPS变化再决定要不要推广。这样演进的风险可控不至于一次改造引入太多变量。这套方案说到底是在延迟、一致性、成本之间找平衡。没有万能的缓存架构只有适不适合当前业务的选择。如果你正在做的项目也遇到Redis压力大、响应时间波动明显的问题照着这篇文章的思路先搭一版多级缓存再用监控数据去调参相信很快就能看到效果。
作为一个常年跟缓存打交道的后端开发多级缓存这个方案我前后在不同项目里折腾过好几轮从最开始的Redis单打独斗到后面扛不住流量把Caffeine加进来踩了不少坑也沉淀了不少经验。今天这篇就把SpringBoot Caffeine Redis这套多级缓存的完整实现思路、核心代码、参数调优和排坑记录一次性整理出来希望能帮到正在做缓存设计或者被缓存击穿搞得头疼的朋友。先从问题说起。大部分业务系统最开始用Redis做缓存简单直接撑个几百上千的QPS问题不大。但等流量上来或者遇到热点key集中访问时Redis的网络IO和序列化开销就会成为瓶颈。尤其是那种单key每秒几万次读的业务哪怕Redis再快一次网络往返下来耗时和带宽压力都很明显。我见过有的团队为了让Redis抗住热点把过期时间越调越短结果又引发缓存击穿DB直接被冲垮。这套方案的核心思路很简单把缓存分成两层热数据放本地全量数据放远端先查本地再查远端本地没有才走网络。本地缓存用Caffeine基于进程内存纳秒级访问零网络开销Redis负责多实例共享数据承担回源数据库的压力。两层配合既能扛高并发又能保证数据在多节点间基本一致。这套方案适合谁来参考如果你正在做SpringBoot项目业务上有明显的读多写少场景比如商品详情、用户信息、配置数据或者你的服务已经部署了多实例Redis的QPS和带宽快吃满那么这个方案可以直接抄作业。如果你的项目还是单机部署、并发量不高我建议先别急着上多级缓存Redis单层足够多级反而增加一致性和运维复杂度。1. 方案选型为什么是Caffeine Redis而不是别的组合先聊选型。本地缓存的选项其实不少老牌的Guava Cache、Ehcache新兴的Caffeine还有简单粗暴的ConcurrentHashMap。我并不是说其他的不行但各有使用场景。ConcurrentHashMap适合纯本地小数据量的读写缺淘汰策略没内存控制容易OOMGuava Cache功能完整但性能不如Caffeine尤其是高并发读写场景下差距明显Ehcache算是老将偏向于需要落盘、堆外缓存等重量级需求在SpringBoot生态里配置偏重。Caffeine是受Guava启发重写的本地缓存库在内存管理、淘汰算法、并发控制上都做得更极致也是目前Spring Boot默认支持的本地缓存方案之一。它基于W-TinyLFU淘汰算法维护一个频率布隆过滤器和两个LRU窗口既能识别热点数据长期保留又能让低频数据快速让位实测下来本地缓存的命中率比Guava要高不少。再聊Redis这层的定位。Redis负责的是跨节点的全局缓存。多实例部署的时候A节点的本地缓存和B节点是各自独立的如果数据只在Caffeine里用户请求落到B节点就查不到所以需要一个共享层兜底。Redis作为共享层核心作用不是抗所有请求而是做数据回源和一致性锚点。换句话说热点数据尽量在Caffeine层消化Redis承受的请求越少整体延迟和带宽压力越低。从技术生态的角度看Caffeine有Spring Boot官方starter适配Redis有Spring Data Redis支持两个都跟SpringBoot配合得很好引入成本很低。我最早也考虑过把Redis换成内存数据库或者直接上CDN但对大多数业务系统来说太重了而且Redis在持久化、过期策略、集群方案上已经足够成熟。本地缓存 分布式缓存是目前性价比最高、最容易被团队接受的多级缓存组合。选型上还有一个容易忽略的点Caffeine是单机缓存每次服务重启、发布时必然全部清空如果直接把Caffeine当作数据的主缓存层会在发布瞬间给Redis带来一波穿透流量。Redis虽然比DB能扛但上千个key同时回源也不是小压力。所以必须给Redis设置合理的过期时间和空值缓存策略把穿透压力挡在DB之外这点我会在后面排坑部分详细说。2. 核心流程设计两级缓存怎么配合工作多级缓存的设计核心是读流程和写流程。先说读流程这个最直观。2.1 读缓存流程先本地再Redis再DB逐级回填一次读请求进来顺序是这样的查Caffeine如果命中直接返回请求结果这个阶段没有任何网络IO性能接近直接读内存。Caffeine未命中查Redis如果命中把数据回填到Caffeine然后返回结果。Redis也未命中查数据库拿到数据后依次回填Redis和Caffeine然后返回结果。这个流程在代码层面就是一层一层的if判断。有个细节我最早没注意结果导致Caffeine没起到缓存作用回填Caffeine的时候一定要把从Redis拿到的数据先反序列化成对象再放入本地缓存而不是把Redis的原始JSON字符串直接放进去。否则每次从Caffeine取出的都是同一个字符串对象业务层还得重复解析性能优势损耗大半。再一个细节是并发的控制。缓存未命中时如果上百个线程同时查到同一个key全部回源DB就会产生缓存击穿。Redis层可以借助分布式锁来保证单线程回源Caffeine层有现成的get(key, mappingFunction)方法能保证单个key只有一个线程执行加载逻辑其他的等待结果返回。多级缓存的每层都要有这层并发保护否则上层缓存恢复的速度赶不上穿透的速度DB还是会被冲垮。读流程的代码骨架看起来不复杂真正复杂的是数据回填时的过期时间策略。热点数据回填到Caffeine可以用相对较短的过期时间比如几分钟到十几分钟因为本地缓存更新快、粒度小Redis的过期时间建议设置得长一些因为Redis的数据要被所有实例共享而且多实例场景下Caffeine过期后还能回到Redis查Redis这层能撑多久直接决定了DB能休息多久。2.2 写缓存流程先写DB再删缓存两级都要管写流程比读流程更容易出问题。最简单的缓存更新策略有三种先更新DB再更新缓存、先删缓存再更新DB、先更新DB再删缓存。我直接说结论主流方案是先更新数据库再删除缓存也就是经典的Cache Aside模式。原因是更新和删除相比更新缓存在并发写场景下容易出现过期数据覆盖新数据的问题而删除缓存即使删慢了一点最多就是多一次缓存穿透数据正确性影响小。删除的时候需要同时删Redis和Caffeine但Caffeine删除只能删除当前节点其他节点的Caffeine还会保留一段时间的老数据所以对一致性的要求不能定得太高。有一种情况要特别小心更新DB成功后删除Redis失败就会导致DB和Redis数据不一致。解决方案有两个方向。第一个是引入可靠消息重试把删除消息发到队列异步消费重试第二个是采用延迟双删先删除缓存再更新DB隔一段时间再删除一次缓存。这两种方案我在生产环境都试过消息重试适合数据变更频繁、失败容忍度低的场景实现起来稍微啰嗦一点延迟双删实现简单但双删的时间间隔不好把握太短会删除过早太长会放大数据不一致窗口。从实际经验看大多数业务系统对数据一致性的容忍窗口在几百毫秒到几秒之间延迟双删配合短TTL已经够用。如果业务方对一致性要求极高比如库存、资金这类就不建议用缓存或者最多用很短的TTL兜底否则一致性设计会让你陷入无尽的复杂度里。2.3 缓存过期策略本地短过期、远端长过期过期时间的设计是多级缓存最容易忽略但影响最大的细节。如果Caffeine和Redis都设置同样的过期时间会出现一个尴尬的现象Caffeine在某个key过期后的同一时间点大量请求同时穿透到RedisRedis全部未命中后同时回源DB刚好形成了一次集中穿透。所以最好给两层缓存设置不同的过期时间并且给同一层内的key设置随机偏移把击穿的时间点打散。我一般在项目里这么定Caffeine过期时间3到10分钟根据业务实时性要求灵活调整偏向短一些。Redis过期时间30到60分钟偏向长一些。Redis的TTL在写入时加上随机值偏移范围是基础值的1到5分钟。为什么要这么设计本地缓存过期了还能去Redis查Redis兜底时间越长DB被查询的频率就越低。而Redis过期时间分散后就算Caffeine短时间内全部失效也不会同时穿透同一个key。至于那些跨节点的一致性需求因为Caffeine过期时间足够短最迟几分钟内所有节点最终能拿到新数据。3. 项目实操SpringBoot代码实现与参数配置开始写代码之前先把依赖和基础环境准备好。这个项目沿用了我在生产环境里的标准配置SpringBoot 2.7.x Caffeine 2.9.x Redis 6.x。3.1 引入依赖与基础配置在pom.xml里加三个关键的依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencySpring Cache的抽象层主要用来管理缓存的注解和声明式缓存策略。但如果只是为了做多级缓存完全没必要用Cacheable注解硬套因为注解方式的缓存管理粒度不够细两级缓存的顺序控制也不够直观。这里我直接封装了一个缓存工具类手动控制读取和回填流程比注解更可控。然后是application.yml里Redis和Caffeine的基础配置。Redis要配置连接池连接池参数直接影响高并发下Redis的稳定性。Caffeine部分用CacheString, Object手动构建配置写在Java类里更清晰。spring: redis: host: 127.0.0.1 port: 6379 timeout: 2000ms lettuce: pool: max-active: 100 max-idle: 50 min-idle: 10 max-wait: 500msRedis连接池的线程模型特别值得多说一句。Spring Boot 2.x默认使用Lettuce连接池Lettuce本身是异步客户端线程安全连接可以复用。但max-active不要盲目调大。我曾经在一台8核16G的机器上把max-active调到200结果Redis没挂应用先频繁Full GC因为连接的缓冲区和监听器对象全是内存开销。正常情况下单实例Redismax-active在50到100之间足够用。3.2 Caffeine缓存配置类Caffeine的配置可以直接写在配置类里通过一个CacheString, Object实例来管理。字段定义很简单但这个配置的每一行都值得推敲。Configuration public class CacheConfig { Bean(localCache) public CacheString, Object localCache() { return Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() .build(); } }maximumSize决定本地缓存的条目上限。这个值一旦设置不合理要么内存浪费要么缓存频繁被淘汰导致命中率低于预期。我通常的估算方式是按业务key数量乘上平均对象大小。比如一个商品详情对象序列化后大概5KB缓存1万个key内存占用差不多50MB对于动辄几G堆内存的应用来说完全能接受。但如果你缓存的对象里有大字符串或者嵌套集合就得按10倍甚至更大的余量去评估。expireAfterWrite(5, TimeUnit.MINUTES)是写入后5分钟过期。这里没有用expireAfterAccess因为后者在热点数据的持续访问下可能永远不过期容易让数据长期处于陈旧状态。实时性要求高的数据先用expireAfterWrite让缓存数据有固定的更新节奏。recordStats()官方的说法是开启命中率统计实际用的时候这个开关影响很小但能让我们在监控里看到Caffeine的命中率、加载次数和淘汰数量。生产环境中我是直接把CacheStats定时打到监控面板这样能直观判断缓存层是否在正常工作。3.3 多级缓存操作类封装接下来是核心代码。整体思路不绕弯子一个方法实现读缓存逻辑另一个方法实现写缓存逻辑缓存值统一用JSON字符串存储。Component public class CacheManager { private static final JsonUtil JSON new JsonUtil(); private static final String CACHE_PREFIX biz:cache:; Resource private CacheString, Object localCache; Resource private RedisTemplateString, Object redisTemplate; /** * 读取缓存 * 顺序本地 - Redis - DB */ public T T get(String key, ClassT clazz, CacheLoaderT loader) { // 1. 本地缓存 Object cacheValue localCache.getIfPresent(key); if (cacheValue ! null) { return (T) cacheValue; } // 2. Redis缓存 String redisKey CACHE_PREFIX key; Object redisValue redisTemplate.opsForValue().get(redisKey); if (redisValue ! null) { T value JSON.parseObj(redisValue.toString(), clazz); // 回填本地缓存 localCache.put(key, value); return value; } // 3. 数据库加载 T value loader.load(); if (value null) { // 空值缓存防止缓存穿透 redisTemplate.opsForValue().set(redisKey, , 300 randomTimeOffset(), TimeUnit.SECONDS); localCache.put(key, null, Duration.ofSeconds(300)); return null; } // 4. 回填Redis与本地 redisTemplate.opsForValue().set(redisKey, JSON.toJsonStr(value), expireTime randomTimeOffset(), TimeUnit.SECONDS); localCache.put(key, value); return value; } /** * 更新缓存 * 先更新DB再删缓存 */ public void update(String key, Object dbData) { // 这里由调用方先完成DB update然后调用本方法 String redisKey CACHE_PREFIX key; redisTemplate.delete(redisKey); localCache.invalidate(key); } private long randomTimeOffset() { return ThreadLocalRandom.current().nextLong(60, 300); } }我特别解释一下空值缓存。第一次写这套缓存时发现某个key在DB里查不到业务上还是会以高频的方式重复查询于是每次查询都直接打到DB上这就是典型的缓存穿透。空值缓存就是在Redis和Caffeine里都给“查不到”的结果放一个占位符并给一个极短的过期时间。这样DB不会被无意义的查询打爆又保证数据一旦写入很快能被读到。Redis那边为了区分正常值和空值我的做法是统一用空字符串占位读取时如果值是空字符串直接返回null就不再向下穿透。另外要注意loader.load()这段的并发控制。上面代码看起来简单但多个线程同时发现本地缓存没有、Redis也没有时依然会同时调用loader.load()回源数据库这不是多级缓存该有的表现。实际项目中需要给Redis那段加分布式锁Java实现一般用Redis的SET key value NX EX命令或者Redisson框架保证同一时刻只有一个线程回源数据库其余线程等待锁释放后再重新查缓存。Caffeine的get(key, mappingFunction)虽然能保证本地单key只加载一次但Redis那层没有这个语义。3.4 Redis序列化配置RedisTemplate默认使用JDK序列化存进去的内容是一堆二进制不仅体积大而且没法直观地排查问题。必须自定义序列化方案生产环境我是用GenericJackson2JsonRedisSerializer。Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // 使用GenericJackson2JsonRedisSerializer GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(serializer); template.setValueSerializer(serializer); template.setHashKeySerializer(serializer); template.setHashValueSerializer(serializer); template.afterPropertiesSet(); return template; } }这里有个坑GenericJackson2JsonRedisSerializer在反序列化时会携带class类型信息如果缓存的POJO类发生了字段变更可能直接反序列化失败。我曾经遇到过一个字段被重命名旧缓存里的JSON还带着旧字段新代码反序列化时因为class指向的错误字段直接抛异常。后来我改用自定义序列化对象手动存储JSON字符串不用RedisTemplate默认的对象转换然后把反序列化工作交给业务层最大程度避免类型绑定的强耦合。上面工具类里用的就是这种思路。4. 方案细化多级缓存的性能对比压测光说不练等于白搭。我在一个模拟项目X里搭了一套完整的多级缓存环境数据库用MySQLRedis单机服务单实例。压测工具用的是wrk压测场景是模拟商品详情的读请求key数量固定5000个并发线程50持续压测5分钟。先看测试对比数据方案平均响应时间(ms)99分位响应时间(ms)实际QPS命中率说明无缓存直连DB28.462.1约1800无命中Redis单层缓存6.815.3约7600Redis命中率约99%CaffeineRedis多级缓存1.64.2约15000Caffeine命中率约88%注意这里Caffeine的命中率88%说明大约88%的请求走到了本地内存只有12%经过网络访问Redis。Redis层的QPS大概在1800左右远比单层Redis方案的7600低。网络IO的节省是响应时间大幅下降的核心原因。Redis单层虽然平均6.8ms但在高并发下受限于网络带宽和连接池复用延迟波动会明显上升。多级缓存把87%以上的请求挡在本地后Redis的压力骤降网络抖动的影响也被隔离了。我压测时发现一个有意思的细节如果压测前把Caffeine的maximumSize调大或者调小命中率变化非常大。5000个key的测试场景maximumSize设置5000时Caffeine命中率达到88%如果再降一倍到2500命中率直接掉到70%响应时间立刻上涨。这个现象给后来的参数调优提了个醒本地缓存的容量不能拍脑袋定最好能根据业务的key规模来动态推算留足余量。再看一个我特意测过的场景全缓存失效瞬间的表现。压测前把所有缓存清空同时发起满负荷请求观察这几个方案的DB压力场景DB高峰QPS高峰持续时间响应时间抖动Redis单层无锁约1800持续至缓存重建p99飙升至800msRedis单层互斥锁约300约3秒p99轻微上升多级缓存互斥锁约150约0.8秒p99轻微上升多级缓存在缓存全清后恢复最快因为Caffeine本身重建极快Redis的回源由分布式锁限流DB根本感知不到大流量。这也是多级缓存在高并发系统里最有价值的地方。5. 坑点解析与排查经验缓存穿透、击穿与雪崩多级缓存不是加上就完事了里面暗藏的风险很多这部分全部来自我真实踩坑后的复盘。5.1 缓存穿透查不到的数据也要缓存穿透是指请求查找一个DB里也不存在的数据缓存层永远没命中所有请求都打到DB。这是最容易被忽略的场景。有些开发觉得“查不到说明无数据缓存里存null也没什么用”但他们没想明白攻击者或者异常用户可以用大量不存在的ID高频请求流量全打在DB上DB会被拖垮。解决方案我在代码里已经给出了空值缓存。哪怕查询结果是null也把它放进缓存里并设置短TTL比如30秒到5分钟。这样同一个无效key的第二次查询开始就能挡住。数据库层面的兜底方案是布隆过滤器把存在的ID提前加载到布隆过滤器里请求来了先判断ID是否存在不存在直接返回但这个方案维护成本高而且布隆过滤器更新和业务写入的一致性不太好处理我没上。5.2 缓存击穿热点key必须加锁击穿是指某个热点key的缓存到了过期时间刚好在这个时间点有大量请求访问缓存未命中导致所有请求同时穿透到DB。多级缓存结构里Caffeine和Redis任意一层的过期都可能导致下一层被穿透。解决办法有两个层次。Caffeine层用Cache.get(key, mappingFunction)它能保证同一个key只有一个线程执行加载逻辑其他线程等待结果但要注意mappingFunction执行期间其他线程是阻塞的如果加载DB特别慢请求会排队积压。Redis层加分布式锁参考代码里读缓存流程那段要用setIfAbsent拿锁拿锁成功的线程去DB查询并回填缓存等锁失败的线程休眠一小段时间后重新查缓存。我习惯用Redisson的RLock它的waitTime和leaseTime可以控制最长等待和锁自动释放避免死锁。5.3 缓存雪崩大批key同时过期雪崩是指大量缓存在同一时间过期导致请求全部回源DB。多级缓存天然对雪崩有缓解作用因为Caffeine和Redis的过期时间是错开的Caffeine没过期前Redis的过期影响不大。但Caffeine如果全量清空呢比如服务发布重启这个场景实际上很常见。每次重启本地缓存全部消失瞬间所有请求都打到Redis如果Redis再来一次大规模过期DB瞬间压力爆炸。我使用的方案是多层缓冲Redis的TTL制定时增加随机偏移比如60分钟加1到5分钟的随机数避免同一时刻大规模过期。对热点key设置永久缓存或绝长TTL配合后台定时刷新任务避免缓存自然过期。服务重启时先触发一次缓存预热把热点数据提前加载到Caffeine让刚启动的实例不至于空缓存接流量。这三板斧叠加下来缓存雪崩基本被挡在可控范围内。5.4 数据一致性删缓存失败怎么兜底前面提到过先更新DB再删除缓存的方案。但删除Redis缓存可能失败一旦失败数据就会在TTL内不一致。这个问题在生产环境出现的概率不低尤其是网络抖动、Redis连接池满了的时候。我的兜底方案比较简单直接借助Spring的定时任务做增量扫描把删除失败的key重新清一遍。具体说更新DB成功后往本地一个延迟队列塞一条记录记录里带着缓存key和期望删除时间后台线程每隔5秒扫描延迟队列到期后统一执行Redis删除如果删除后再次失败记录会重试最多3次。这个方案实现成本低不依赖消息中间件对大多数场景够用了。延迟双删方案我也用过实现更简单但需要根据业务经验估算延迟时间。如果数据库主从同步耗时超过预期双删的时间点就会失效。所以我现在更倾向于延迟队列 失败重试理由是可控性和可观测性更强。5.5 多实例一致性本地缓存更新通知前面聊的缓存更新默认都是单实例视角。生产环境肯定是多实例部署A节点更新了DB并删除了自己Caffeine里的缓存但B节点Cafffeine里的旧数据还留着。这时候有两种选择。一种是接收“本地缓存失效”的广播消息。有了Redis的Pub/Sub或者消息队列A节点删除缓存时发一条通知其他节点收到后也删除自己的本地缓存。这个方案能做到秒级一致但会引入新的中间件依赖和消息丢失风险架构复杂度明显提升。另一种是接受短暂不一致靠Caffeine的短TTL兜底。我在项目里的选择是实时性要求一般的场景用TTL兜底实时性要求较高的独立接口直接绕过本地缓存只走Redis。6. 可观测性建设缓存统计与监控多级缓存做出来后没有监控等于白做。缓存命中率、耗时、容量这些数据必须能看得见否则你根本不知道参数要不要调整。Caffeine自带recordStats()可以通过localCache.stats()拿到hitCount、missCount、evictionCount等指标。我一般直接把CacheStats里的数据封装成指标定时上报到监控大盘。Redis那层的监控相对简单用Spring Data Redis的get和set统计耗时或者直接依赖Redis的INFO命令看内存和连接数。最有价值的指标是两级缓存的命中率变化趋势。如果发现Caffeine命中率持续走低大概率是maximumSize设置太小或者expireAfterWrite太短如果Redis命中率持续走低异常排查方向则是Redis过期时间、数据写入逻辑和缓存预热是否正常。还有一个容易被忽略的监控维度Caffeine的淘汰数量。当淘汰数量暴涨时说明缓存容量已经接近上限热点key在被频繁挤掉这时候就算命中率还没明显变化也要开始扩容或调参了。我的监控指标存到某个时序数据库里用仪表盘可视化。核心指标包括Caffeine命中率、淘汰数、加载数Redis读取耗时、写耗时、连接池活跃连接数DB回源QPS两级缓存的平均过期时间这几项指标加在一起基本能定位90%以上的缓存问题。7. 写在经验之后从单层Redis到多级缓存我最大的体会是整条链路的瓶颈会一直在移动。你解决了Redis的高负载新的瓶颈可能就出现在本地缓存的容量或者GC上你优化了Caffeine的过期策略新的问题可能藏在序列化和反序列化里。多级缓存不是把两个缓存叠起来就完了每一环节都必须配上监控和数据反馈来支撑决策。一个小技巧分享给你如果你不想一开始就把多级缓存铺到所有接口可以先挑几个热点接口加Caffeine让监控跑一周对比Redis的QPS变化再决定要不要推广。这样演进的风险可控不至于一次改造引入太多变量。这套方案说到底是在延迟、一致性、成本之间找平衡。没有万能的缓存架构只有适不适合当前业务的选择。如果你正在做的项目也遇到Redis压力大、响应时间波动明显的问题照着这篇文章的思路先搭一版多级缓存再用监控数据去调参相信很快就能看到效果。
