尧图网站建设 
简介本资源是一份面向Java后端开发者与系统架构师的缓存技术对比教学PPT聚焦本地缓存如Guava Cache、Caffeine与分布式缓存如Redis、Memcache的核心差异系统梳理二者在读写性能、数据一致性、扩容能力、适用场景及典型缺陷等方面的实践要点。资源以单个2.14MB的PPTX文件呈现内容结构清晰涵盖缓存本质定义、本地缓存的高QPS低延迟优势与内存局限、分布式缓存的共享性与高可用设计以及地域信息、数据字典、热点商品等真实业务场景的选型建议。PPT中穿插对比表格、架构示意图与典型代码片段便于快速理解技术边界与落地约束。目前已有1306人学习下载适合中高级开发人员夯实缓存选型能力、规避集群环境下的数据不一致风险并为微服务架构中的缓存分层设计提供可复用的决策框架。1. 本地缓存和分布式缓存不是“二选一”而是“怎么配”一个电商秒杀接口从 500ms 降到 42ms 的真实路径你写完一个商品详情页接口压测 QPS 刚过 800 就开始超时加了 Redis 后吞吐翻了 3 倍但凌晨缓存雪崩导致库存校验错乱后来在服务里又加了一层 Caffeine结果发现热点商品的缓存穿透反而更严重了……这不是玄学是本地缓存与分布式缓存没配对。本地缓存如 Caffeine、Guava Cache跑在 JVM 堆内毫秒级响应、零网络开销但进程隔离、不共享、易被 GC 清洗分布式缓存如 Redis、Tair跨节点一致、容量弹性、支持复杂数据结构却引入网络延迟、序列化开销、连接池瓶颈和脑裂风险。真正落地时没人只用一种——高并发读场景下90% 的请求走本地缓存5% 走 Redis剩下 5% 才打 DB而库存扣减、订单状态变更这类强一致性操作必须绕过本地缓存直写 Redis 并双删。本文不讲概念对比表只拆解一个真实电商秒杀服务的缓存分层策略从代码怎么写、参数怎么调、失效怎么联动到 JVM GC 日志里怎么一眼看出本地缓存正在被频繁驱逐。适合正在做性能优化、准备面试高并发题、或刚被缓存雪崩背锅的后端工程师。2. 为什么必须分层单用本地缓存或 Redis 都会翻车2.1 本地缓存单点扛不住JVM 堆内缓存的三大硬伤本地缓存本质是堆内 Map 过期策略 回收机制它快得反常也脆得离谱。第一进程隔离性即缺陷K8s 下 10 个 Pod 各自维护一份商品 SKU 缓存更新时需广播通知所有实例否则出现“一个 Pod 显示有货、另一个返回售罄”的脏读。第二GC 友好度极低Caffeine 默认使用 WeakReference 存 key、SoftReference 存 value但大对象如含图片 URL 和规格树的完整商品 POJO一旦进缓存极易触发老年代 GC我们曾在线上看到 Full GC 频率从 2 小时一次飙升到每 8 分钟一次直接拖垮 RT。第三容量不可控maximumSize(10000)看似设了上限但 Caffeine 实际按权重weight计算容量而默认 weight 是 1 —— 若缓存对象平均 2MB10000 条就是 20GB 堆内存OOM 就在下一秒。这不是理论风险是我们某次灰度发布后监控告警的真实截图。2.2 分布式缓存单点撑不住Redis 不是万能胶水把所有缓存逻辑一股脑扔给 Redis看似解耦干净实则埋下三颗雷。第一网络延迟放大效应本地缓存平均 0.08msRedis 单次 GET 在内网通常 0.8–1.5ms当一个商品详情页需查 12 个字段价格、库存、规格、营销标签等串行调用 Redis 就是 12×1.2ms ≈ 14.4ms再叠加上下游服务调用P99 直接破 200ms。第二连接池成为隐形瓶颈Lettuce 默认maxTotal8当 1000 QPS 请求涌来线程阻塞在pool.getResource()上日志里全是Could not get a resource from the pool。第三缓存击穿/穿透/雪崩不是教科书案例是凌晨三点的 PagerDuty 报警秒杀开始前 1 秒10 万请求同时查一个未命中的商品 ID全部穿透到 DBMySQL CPU 瞬间 100%DBA 电话打爆运维手机。这些不是“可能”而是我们用 Redis Cluster 跑了 18 个月后总结出的血泪经验。2.3 分层缓存不是叠加而是职责切分读写分离 生效域隔离真正的分层不是“本地缓存 Redis”而是按数据一致性要求、访问频次、变更频率划出三条线强一致写路径库存扣减、订单创建、支付回调 → 绕过所有缓存直写 DB 双删 Redis先删商品缓存再删聚合缓存弱一致读路径高频静态商品标题、类目、品牌信息 → 本地缓存Caffeine 定时刷新6 小时 reload Redis 作为兜底源弱一致读路径中频动态实时库存、优惠券余量、用户购物车 → 仅 Redis带逻辑过期 互斥锁 本地缓存不参与。关键在“兜底源”设计本地缓存查不到时不直接回源 DB而是查 RedisRedis 也没命中才查 DB 并写入 Redis注意此时不写本地缓存避免脏数据。这个逻辑决定了 99.2% 的请求止步于本地缓存真正打到 Redis 的不足 5%DB 更是低于 0.3%。我们用 Arthas trace 验证过单机 1200 QPS 下本地缓存 hit rate 稳定在 99.17%–99.23%Redis QPS 均值仅 42DB QPS 3.1。3. 本地缓存怎么配Caffeine 的 4 个必调参数与 2 个隐藏陷阱3.1 初始化 Caffeine不是 new Caffeine()而是 build() 前的 4 个生死参数Caffeine 的 builder 模式看着简单但漏掉任意一个参数都可能让缓存变成性能黑洞。以下是生产环境验证过的最小安全配置CacheString, ProductDetail localCache Caffeine.newBuilder() .maximumSize(5000) // 【必设】硬上限单位是 entry 数量非内存字节 .expireAfterWrite(10, TimeUnit.MINUTES) // 【必设】写入后 10 分钟过期防 stale data .refreshAfterWrite(5, TimeUnit.MINUTES) // 【必设】5 分钟后异步刷新保证热点数据不过期 .weigher((key, value) - { // 【必设】自定义权重计算避免 OOM —— 按实际字节数估算 return (int) Math.ceil(SizeOfObject.sizeOf(value) / 1024.0); }) .recordStats() // 【建议】开启统计后续用 metrics 检查 hitRate .build(key - loadFromRedis(key)); // 【核心】loadFunction 必须指向 Redis而非 DB提示maximumSize和weigher必须成对出现。若只设maximumSizeCaffeine 按 entry 数计数一个 5MB 的商品对象占 1 个 slot1000 个就吃掉 5GB 堆加上weigher后按字节算权重5000 权重上限 ≈ 5MB 缓存总容量这才是可控的。3.2 refreshAfterWrite 的真实行为不是定时任务而是“懒加载式续命”很多工程师以为refreshAfterWrite(5, MINUTES)是每隔 5 分钟自动 reload 一次这是巨大误解。它的实际逻辑是当某个 key 被访问且距上次写入已超 5 分钟Caffeine 会异步触发 loadFunction即loadFromRedis同时立即返回旧值。这意味着用户无感知延迟旧值秒回新值在后台静默更新下次访问即生效若loadFromRedis抛异常旧值继续保留不会清空异步线程由 Caffeine 内部 ForkJoinPool 执行无需额外线程池。我们曾因没理解这点在loadFromRedis里写了耗时 200ms 的降级逻辑查 DB导致大量异步任务堆积ForkJoinPool 队列满最终cache.get(key)阻塞超时。解决方案在loadFromRedis外包一层try-catch捕获异常后快速返回 null并记录 warn 日志。3.3 recordStats 的监控接入别只看 hitRate要盯住 evictionCountCaffeine 的Cache.stats()返回CacheStats对象其中hitRate()常被当作黄金指标但它会掩盖致命问题。真正要盯的是evictionCount()单位时间被驱逐的 entry 数。若每分钟 100说明maximumSize或weigher设置过小缓存频繁抖动loadSuccessCount()/loadFailureCount()反映下游 Redis 是否稳定。失败率突增大概率是 Redis 连接池耗尽或超时totalLoadTime()所有 load 操作总耗时。若该值持续增长说明loadFromRedis本身变慢可能是 Redis 响应延迟升高。我们在 Grafana 中将这三项指标与 JVM GC 次数同屏展示发现evictionCount每小时规律性峰值对应定时任务批量刷缓存立刻定位到某 cron 任务在凌晨 2 点全量预热商品缓存但没控制并发数瞬间塞入 2 万个大对象触发 Caffeine 主动驱逐。解决方法改用asMap().putAll()分批写入每批 ≤ 500 条。4. 分布式缓存怎么配Redis 的 3 层防护与 1 个反模式4.1 第一层防护连接池不是越大越好而是要匹配业务毛刺Lettuce 连接池参数不是拍脑袋定的。我们通过redis-cli --latency测得线上 Redis P99 延迟为 1.3ms单次命令耗时可视为 1.5ms。假设业务允许单次接口最大耗时 50ms则单个连接最多承载50 / 1.5 ≈ 33个并发请求。若应用 QPS 为 1200平均每个请求调用 Redis 3 次GET ×3则所需连接数理论值为(1200 × 3) / 33 ≈ 110。但必须预留毛刺缓冲——秒杀峰值 QPS 达 8000瞬时连接需求(8000 × 3) / 33 ≈ 727。因此最终配置lettuce: pool: max-active: 200 # 核心连接数覆盖日常流量 max-idle: 200 min-idle: 50 max-wait: 1000ms # 关键超时必须设否则线程卡死 time-between-eviction-runs: 30000ms # 每 30 秒检测空闲连接注意max-wait是救命参数。若不设当连接池耗尽线程会无限等待整个 Tomcat 线程池被占满服务雪崩。设为 1000ms 后超时直接抛RedisConnectionPoolException上层可降级返回默认值。4.2 第二层防护缓存穿透用“逻辑过期 空值缓存”不用布隆过滤器布隆过滤器Bloom Filter常被推荐防穿透但它在电商场景有硬伤SKU ID 是字符串如 sku_123456789变更频繁下架/复上布隆过滤器重建需全量扫描 DB耗时且易漏。我们采用更轻量的组合拳空值缓存Redis 中SET sku_999999999 EX 6060 秒后自动过期拦截无效 ID逻辑过期存储 JSON 时增加expireAt字段如{data:{...},expireAt:1717023600}Unix 时间戳应用层读取后判断是否过期过期则异步刷新并设置新expireAt互斥锁逻辑过期时用SET sku_123456 NX EX 3获取锁成功者 reload失败者 sleep 50ms 后重试。该方案上线后穿透请求 DB 的比例从 12% 降至 0.03%且无需维护布隆过滤器 bitmap。4.3 第三层防护缓存雪崩用“随机过期 预热”拒绝统一 TTL所有商品缓存设相同 TTL如EX 3600是雪崩温床。我们改为随机化 TTLEX ${3600 random.nextInt(600)}即 1 小时 ± 10 分钟分级预热凌晨 1 点起每 15 分钟用脚本批量加载 5000 个高热 SKU 到 Redis避免早高峰集中重建降级开关配置中心控制cache.enabledtrue/false雪崩时一键关闭缓存直连 DBDB 已按 3 倍容量扩容。5. 本地缓存与分布式缓存的联动失效同步不是靠消息队列而是“双删 版本号”5.1 为什么不能用 MQ 同步本地缓存失效MQ 方案看似优雅DB 更新 → 发 MQ → 各实例消费 →localCache.invalidate(key)。但它在实践中崩得干脆消息丢失网络抖动、MQ Broker 重启一条消息丢了某个 Pod 的本地缓存就永久脏了顺序错乱MQ 不保证严格有序update stock100消息晚于update stock99到达本地缓存值反而变大消费延迟Kafka 消费者组 rebalance 期间消息积压数分钟缓存不一致窗口过长。我们彻底弃用 MQ改用“双删 版本号”硬核方案。5.2 双删 版本号DB 更新时的 4 步原子操作以库存扣减为例标准流程如下全部在同一个 DB 事务内删本地缓存本机localCache.invalidate(sku_123456)删 Redis 缓存redis.del(sku_123456)更新 DB 库存UPDATE inventory SET stock stock - 1 WHERE sku_id 123456 AND stock 1写入新版本号redis.setex(sku_123456:version, 3600, System.currentTimeMillis())。关键细节第 1 步删的是本机缓存不是发指令给其他机器——因为其他机器根本不知道这次更新。那它们怎么知道该刷新靠第 4 步的versionkey。所有loadFromRedis(key)方法在读取主缓存前先GET key:version若 version 比本地缓存的 version 字段旧则强制 reload。5.3 版本号如何嵌入缓存数据JSON 结构改造与解析逻辑Redis 中商品缓存不再存裸 JSON而是包装为{ data: { title: iPhone 15, stock: 99 }, version: 1717023600123, timestamp: 1717023600123 }Caffeine 的loadFromRedis方法这样写public ProductDetail loadFromRedis(String skuId) { String cacheKey sku_ skuId; String versionKey cacheKey :version; // 先查版本号 String remoteVersionStr redisTemplate.opsForValue().get(versionKey); long remoteVersion remoteVersionStr ! null ? Long.parseLong(remoteVersionStr) : 0; // 再查主数据 String json redisTemplate.opsForValue().get(cacheKey); if (json null) return null; ProductDetail detail JsonUtil.fromJson(json, ProductDetail.class); // 比较版本若远程 version 更大说明本地缓存已 stale强制刷新 if (detail.getVersion() remoteVersion) { return reloadFromRedis(skuId); // 触发完整 reload } return detail; }这个设计让各实例本地缓存的“新鲜度”差异控制在秒级version key TTL 1 小时但实际更新后立即生效且完全规避了 MQ 的可靠性问题。6. 排查缓存问题的 5 个黑匣子技巧从 GC 日志到 Arthas 火焰图6.1 看懂 Caffeine 的 GC 日志不是看 Full GC而是看 PS Old Gen 的“缓存驱逐痕迹”JVM 参数-XX:PrintGCDetails -Xloggc:gc.log输出的日志里不要只扫Full GC重点找这一行[PSYoungGen: 123456K-1234K(234560K)] 456789K-345678K(987654K), 0.1234567 secs]其中456789K-345678K是老年代使用量变化。若每次 GC 后老年代减少量 ≈ 本地缓存maximumSize × avgObjSize例如 5000 × 1MB 5GB说明 Caffeine 正在大量驱逐对象并触发 GC。这时要立刻检查evictionCount()指标而非盲目加大堆内存。6.2 用 Arthas trace 定位缓存穿透不是查 Redis Miss而是查 loadFunction 耗时执行trace com.xxx.cache.LocalCacheLoader loadFromRedis观察输出---ts2024-05-30 10:23:45;thread_namehttp-nio-8080-exec-23;id23;is_daemontrue;priority5;TCCLorg.springframework.boot.loader.LaunchedURLClassLoader2e0fa5d3 ---ts2024-05-30 10:23:45;duration1234ms;classLocalCacheLoader;methodloadFromRedis ---ts2024-05-30 10:23:45;duration1200ms;classStringRedisTemplate;methodopsForValue().get若loadFromRedis耗时 1000ms且opsForValue().get占比 98%说明 Redis 响应慢若loadFromRedis耗时 1200ms 但opsForValue().get只 200ms剩下 1000ms 在JsonUtil.fromJson说明反序列化大 JSON 太慢——这时要压缩 JSON 或改用 Protobuf。6.3 Redis 连接池耗尽的 3 个信号不是连接数告警而是线程堆栈当max-wait超时时jstack pid输出里会出现大量线程卡在http-nio-8080-exec-123 #123 daemon prio5 os_prio0 tid0x00007f8c4c001000 nid0x1a2b waiting on condition [0x00007f8c3a12d000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:423)这就是连接池耗尽的铁证。此时redis-cli info clients中connected_clients会远高于maxclients配置值。6.4 缓存击穿的火焰图特征不是 CPU 高而是线程在 synchronized 块里排队用async-profiler生成火焰图若看到大量线程堆栈集中在com.xxx.service.ProductService.getProductDetail └─ com.xxx.cache.LocalCacheLoader.loadFromRedis └─ com.xxx.cache.RedisLock.tryLock // 自研的 SET NX EX 锁 └─ io.lettuce.core.RedisAsyncCommandsImpl.get且tryLock占比 40%说明大量请求在争抢同一个 SKU 的互斥锁正是击穿典型表现。此时要检查tryLock的超时时间是否过长我们设为 100ms超过则降级返回空。6.5 本地缓存污染的终极验证用 jmap 导出堆内存MAT 查 Object Histogram执行jmap -dump:formatb,fileheap.hprof pid用 Eclipse MAT 打开执行Histogram输入com.github.benmanes.caffeine.cache.BoundedLocalCache看Retained Heap是否异常高。若单个BoundedLocalCache占用 500MB说明weigher失效或maximumSize设得太松必须立即调整。我踩过最深的坑是在测试环境用maximumSize(10000)跑得好好的上线后因商品 POJO 加了新字段单个对象从 120KB 涨到 1.8MB10000 条直接吃掉 18GB 堆Full GC 每 3 分钟一次。后来养成了铁律——每次新增缓存字段必须用SizeOfObject.sizeOf(obj)测一遍对象大小再反推weigher公式。希望帮到你。本文还有配套的精品资源点击获取 电商秒杀缓存分层实战：本地缓存与Redis协同优化
简介本资源是一份面向Java后端开发者与系统架构师的缓存技术对比教学PPT聚焦本地缓存如Guava Cache、Caffeine与分布式缓存如Redis、Memcache的核心差异系统梳理二者在读写性能、数据一致性、扩容能力、适用场景及典型缺陷等方面的实践要点。资源以单个2.14MB的PPTX文件呈现内容结构清晰涵盖缓存本质定义、本地缓存的高QPS低延迟优势与内存局限、分布式缓存的共享性与高可用设计以及地域信息、数据字典、热点商品等真实业务场景的选型建议。PPT中穿插对比表格、架构示意图与典型代码片段便于快速理解技术边界与落地约束。目前已有1306人学习下载适合中高级开发人员夯实缓存选型能力、规避集群环境下的数据不一致风险并为微服务架构中的缓存分层设计提供可复用的决策框架。1. 本地缓存和分布式缓存不是“二选一”而是“怎么配”一个电商秒杀接口从 500ms 降到 42ms 的真实路径你写完一个商品详情页接口压测 QPS 刚过 800 就开始超时加了 Redis 后吞吐翻了 3 倍但凌晨缓存雪崩导致库存校验错乱后来在服务里又加了一层 Caffeine结果发现热点商品的缓存穿透反而更严重了……这不是玄学是本地缓存与分布式缓存没配对。本地缓存如 Caffeine、Guava Cache跑在 JVM 堆内毫秒级响应、零网络开销但进程隔离、不共享、易被 GC 清洗分布式缓存如 Redis、Tair跨节点一致、容量弹性、支持复杂数据结构却引入网络延迟、序列化开销、连接池瓶颈和脑裂风险。真正落地时没人只用一种——高并发读场景下90% 的请求走本地缓存5% 走 Redis剩下 5% 才打 DB而库存扣减、订单状态变更这类强一致性操作必须绕过本地缓存直写 Redis 并双删。本文不讲概念对比表只拆解一个真实电商秒杀服务的缓存分层策略从代码怎么写、参数怎么调、失效怎么联动到 JVM GC 日志里怎么一眼看出本地缓存正在被频繁驱逐。适合正在做性能优化、准备面试高并发题、或刚被缓存雪崩背锅的后端工程师。2. 为什么必须分层单用本地缓存或 Redis 都会翻车2.1 本地缓存单点扛不住JVM 堆内缓存的三大硬伤本地缓存本质是堆内 Map 过期策略 回收机制它快得反常也脆得离谱。第一进程隔离性即缺陷K8s 下 10 个 Pod 各自维护一份商品 SKU 缓存更新时需广播通知所有实例否则出现“一个 Pod 显示有货、另一个返回售罄”的脏读。第二GC 友好度极低Caffeine 默认使用 WeakReference 存 key、SoftReference 存 value但大对象如含图片 URL 和规格树的完整商品 POJO一旦进缓存极易触发老年代 GC我们曾在线上看到 Full GC 频率从 2 小时一次飙升到每 8 分钟一次直接拖垮 RT。第三容量不可控maximumSize(10000)看似设了上限但 Caffeine 实际按权重weight计算容量而默认 weight 是 1 —— 若缓存对象平均 2MB10000 条就是 20GB 堆内存OOM 就在下一秒。这不是理论风险是我们某次灰度发布后监控告警的真实截图。2.2 分布式缓存单点撑不住Redis 不是万能胶水把所有缓存逻辑一股脑扔给 Redis看似解耦干净实则埋下三颗雷。第一网络延迟放大效应本地缓存平均 0.08msRedis 单次 GET 在内网通常 0.8–1.5ms当一个商品详情页需查 12 个字段价格、库存、规格、营销标签等串行调用 Redis 就是 12×1.2ms ≈ 14.4ms再叠加上下游服务调用P99 直接破 200ms。第二连接池成为隐形瓶颈Lettuce 默认maxTotal8当 1000 QPS 请求涌来线程阻塞在pool.getResource()上日志里全是Could not get a resource from the pool。第三缓存击穿/穿透/雪崩不是教科书案例是凌晨三点的 PagerDuty 报警秒杀开始前 1 秒10 万请求同时查一个未命中的商品 ID全部穿透到 DBMySQL CPU 瞬间 100%DBA 电话打爆运维手机。这些不是“可能”而是我们用 Redis Cluster 跑了 18 个月后总结出的血泪经验。2.3 分层缓存不是叠加而是职责切分读写分离 生效域隔离真正的分层不是“本地缓存 Redis”而是按数据一致性要求、访问频次、变更频率划出三条线强一致写路径库存扣减、订单创建、支付回调 → 绕过所有缓存直写 DB 双删 Redis先删商品缓存再删聚合缓存弱一致读路径高频静态商品标题、类目、品牌信息 → 本地缓存Caffeine 定时刷新6 小时 reload Redis 作为兜底源弱一致读路径中频动态实时库存、优惠券余量、用户购物车 → 仅 Redis带逻辑过期 互斥锁 本地缓存不参与。关键在“兜底源”设计本地缓存查不到时不直接回源 DB而是查 RedisRedis 也没命中才查 DB 并写入 Redis注意此时不写本地缓存避免脏数据。这个逻辑决定了 99.2% 的请求止步于本地缓存真正打到 Redis 的不足 5%DB 更是低于 0.3%。我们用 Arthas trace 验证过单机 1200 QPS 下本地缓存 hit rate 稳定在 99.17%–99.23%Redis QPS 均值仅 42DB QPS 3.1。3. 本地缓存怎么配Caffeine 的 4 个必调参数与 2 个隐藏陷阱3.1 初始化 Caffeine不是 new Caffeine()而是 build() 前的 4 个生死参数Caffeine 的 builder 模式看着简单但漏掉任意一个参数都可能让缓存变成性能黑洞。以下是生产环境验证过的最小安全配置CacheString, ProductDetail localCache Caffeine.newBuilder() .maximumSize(5000) // 【必设】硬上限单位是 entry 数量非内存字节 .expireAfterWrite(10, TimeUnit.MINUTES) // 【必设】写入后 10 分钟过期防 stale data .refreshAfterWrite(5, TimeUnit.MINUTES) // 【必设】5 分钟后异步刷新保证热点数据不过期 .weigher((key, value) - { // 【必设】自定义权重计算避免 OOM —— 按实际字节数估算 return (int) Math.ceil(SizeOfObject.sizeOf(value) / 1024.0); }) .recordStats() // 【建议】开启统计后续用 metrics 检查 hitRate .build(key - loadFromRedis(key)); // 【核心】loadFunction 必须指向 Redis而非 DB提示maximumSize和weigher必须成对出现。若只设maximumSizeCaffeine 按 entry 数计数一个 5MB 的商品对象占 1 个 slot1000 个就吃掉 5GB 堆加上weigher后按字节算权重5000 权重上限 ≈ 5MB 缓存总容量这才是可控的。3.2 refreshAfterWrite 的真实行为不是定时任务而是“懒加载式续命”很多工程师以为refreshAfterWrite(5, MINUTES)是每隔 5 分钟自动 reload 一次这是巨大误解。它的实际逻辑是当某个 key 被访问且距上次写入已超 5 分钟Caffeine 会异步触发 loadFunction即loadFromRedis同时立即返回旧值。这意味着用户无感知延迟旧值秒回新值在后台静默更新下次访问即生效若loadFromRedis抛异常旧值继续保留不会清空异步线程由 Caffeine 内部 ForkJoinPool 执行无需额外线程池。我们曾因没理解这点在loadFromRedis里写了耗时 200ms 的降级逻辑查 DB导致大量异步任务堆积ForkJoinPool 队列满最终cache.get(key)阻塞超时。解决方案在loadFromRedis外包一层try-catch捕获异常后快速返回 null并记录 warn 日志。3.3 recordStats 的监控接入别只看 hitRate要盯住 evictionCountCaffeine 的Cache.stats()返回CacheStats对象其中hitRate()常被当作黄金指标但它会掩盖致命问题。真正要盯的是evictionCount()单位时间被驱逐的 entry 数。若每分钟 100说明maximumSize或weigher设置过小缓存频繁抖动loadSuccessCount()/loadFailureCount()反映下游 Redis 是否稳定。失败率突增大概率是 Redis 连接池耗尽或超时totalLoadTime()所有 load 操作总耗时。若该值持续增长说明loadFromRedis本身变慢可能是 Redis 响应延迟升高。我们在 Grafana 中将这三项指标与 JVM GC 次数同屏展示发现evictionCount每小时规律性峰值对应定时任务批量刷缓存立刻定位到某 cron 任务在凌晨 2 点全量预热商品缓存但没控制并发数瞬间塞入 2 万个大对象触发 Caffeine 主动驱逐。解决方法改用asMap().putAll()分批写入每批 ≤ 500 条。4. 分布式缓存怎么配Redis 的 3 层防护与 1 个反模式4.1 第一层防护连接池不是越大越好而是要匹配业务毛刺Lettuce 连接池参数不是拍脑袋定的。我们通过redis-cli --latency测得线上 Redis P99 延迟为 1.3ms单次命令耗时可视为 1.5ms。假设业务允许单次接口最大耗时 50ms则单个连接最多承载50 / 1.5 ≈ 33个并发请求。若应用 QPS 为 1200平均每个请求调用 Redis 3 次GET ×3则所需连接数理论值为(1200 × 3) / 33 ≈ 110。但必须预留毛刺缓冲——秒杀峰值 QPS 达 8000瞬时连接需求(8000 × 3) / 33 ≈ 727。因此最终配置lettuce: pool: max-active: 200 # 核心连接数覆盖日常流量 max-idle: 200 min-idle: 50 max-wait: 1000ms # 关键超时必须设否则线程卡死 time-between-eviction-runs: 30000ms # 每 30 秒检测空闲连接注意max-wait是救命参数。若不设当连接池耗尽线程会无限等待整个 Tomcat 线程池被占满服务雪崩。设为 1000ms 后超时直接抛RedisConnectionPoolException上层可降级返回默认值。4.2 第二层防护缓存穿透用“逻辑过期 空值缓存”不用布隆过滤器布隆过滤器Bloom Filter常被推荐防穿透但它在电商场景有硬伤SKU ID 是字符串如 sku_123456789变更频繁下架/复上布隆过滤器重建需全量扫描 DB耗时且易漏。我们采用更轻量的组合拳空值缓存Redis 中SET sku_999999999 EX 6060 秒后自动过期拦截无效 ID逻辑过期存储 JSON 时增加expireAt字段如{data:{...},expireAt:1717023600}Unix 时间戳应用层读取后判断是否过期过期则异步刷新并设置新expireAt互斥锁逻辑过期时用SET sku_123456 NX EX 3获取锁成功者 reload失败者 sleep 50ms 后重试。该方案上线后穿透请求 DB 的比例从 12% 降至 0.03%且无需维护布隆过滤器 bitmap。4.3 第三层防护缓存雪崩用“随机过期 预热”拒绝统一 TTL所有商品缓存设相同 TTL如EX 3600是雪崩温床。我们改为随机化 TTLEX ${3600 random.nextInt(600)}即 1 小时 ± 10 分钟分级预热凌晨 1 点起每 15 分钟用脚本批量加载 5000 个高热 SKU 到 Redis避免早高峰集中重建降级开关配置中心控制cache.enabledtrue/false雪崩时一键关闭缓存直连 DBDB 已按 3 倍容量扩容。5. 本地缓存与分布式缓存的联动失效同步不是靠消息队列而是“双删 版本号”5.1 为什么不能用 MQ 同步本地缓存失效MQ 方案看似优雅DB 更新 → 发 MQ → 各实例消费 →localCache.invalidate(key)。但它在实践中崩得干脆消息丢失网络抖动、MQ Broker 重启一条消息丢了某个 Pod 的本地缓存就永久脏了顺序错乱MQ 不保证严格有序update stock100消息晚于update stock99到达本地缓存值反而变大消费延迟Kafka 消费者组 rebalance 期间消息积压数分钟缓存不一致窗口过长。我们彻底弃用 MQ改用“双删 版本号”硬核方案。5.2 双删 版本号DB 更新时的 4 步原子操作以库存扣减为例标准流程如下全部在同一个 DB 事务内删本地缓存本机localCache.invalidate(sku_123456)删 Redis 缓存redis.del(sku_123456)更新 DB 库存UPDATE inventory SET stock stock - 1 WHERE sku_id 123456 AND stock 1写入新版本号redis.setex(sku_123456:version, 3600, System.currentTimeMillis())。关键细节第 1 步删的是本机缓存不是发指令给其他机器——因为其他机器根本不知道这次更新。那它们怎么知道该刷新靠第 4 步的versionkey。所有loadFromRedis(key)方法在读取主缓存前先GET key:version若 version 比本地缓存的 version 字段旧则强制 reload。5.3 版本号如何嵌入缓存数据JSON 结构改造与解析逻辑Redis 中商品缓存不再存裸 JSON而是包装为{ data: { title: iPhone 15, stock: 99 }, version: 1717023600123, timestamp: 1717023600123 }Caffeine 的loadFromRedis方法这样写public ProductDetail loadFromRedis(String skuId) { String cacheKey sku_ skuId; String versionKey cacheKey :version; // 先查版本号 String remoteVersionStr redisTemplate.opsForValue().get(versionKey); long remoteVersion remoteVersionStr ! null ? Long.parseLong(remoteVersionStr) : 0; // 再查主数据 String json redisTemplate.opsForValue().get(cacheKey); if (json null) return null; ProductDetail detail JsonUtil.fromJson(json, ProductDetail.class); // 比较版本若远程 version 更大说明本地缓存已 stale强制刷新 if (detail.getVersion() remoteVersion) { return reloadFromRedis(skuId); // 触发完整 reload } return detail; }这个设计让各实例本地缓存的“新鲜度”差异控制在秒级version key TTL 1 小时但实际更新后立即生效且完全规避了 MQ 的可靠性问题。6. 排查缓存问题的 5 个黑匣子技巧从 GC 日志到 Arthas 火焰图6.1 看懂 Caffeine 的 GC 日志不是看 Full GC而是看 PS Old Gen 的“缓存驱逐痕迹”JVM 参数-XX:PrintGCDetails -Xloggc:gc.log输出的日志里不要只扫Full GC重点找这一行[PSYoungGen: 123456K-1234K(234560K)] 456789K-345678K(987654K), 0.1234567 secs]其中456789K-345678K是老年代使用量变化。若每次 GC 后老年代减少量 ≈ 本地缓存maximumSize × avgObjSize例如 5000 × 1MB 5GB说明 Caffeine 正在大量驱逐对象并触发 GC。这时要立刻检查evictionCount()指标而非盲目加大堆内存。6.2 用 Arthas trace 定位缓存穿透不是查 Redis Miss而是查 loadFunction 耗时执行trace com.xxx.cache.LocalCacheLoader loadFromRedis观察输出---ts2024-05-30 10:23:45;thread_namehttp-nio-8080-exec-23;id23;is_daemontrue;priority5;TCCLorg.springframework.boot.loader.LaunchedURLClassLoader2e0fa5d3 ---ts2024-05-30 10:23:45;duration1234ms;classLocalCacheLoader;methodloadFromRedis ---ts2024-05-30 10:23:45;duration1200ms;classStringRedisTemplate;methodopsForValue().get若loadFromRedis耗时 1000ms且opsForValue().get占比 98%说明 Redis 响应慢若loadFromRedis耗时 1200ms 但opsForValue().get只 200ms剩下 1000ms 在JsonUtil.fromJson说明反序列化大 JSON 太慢——这时要压缩 JSON 或改用 Protobuf。6.3 Redis 连接池耗尽的 3 个信号不是连接数告警而是线程堆栈当max-wait超时时jstack pid输出里会出现大量线程卡在http-nio-8080-exec-123 #123 daemon prio5 os_prio0 tid0x00007f8c4c001000 nid0x1a2b waiting on condition [0x00007f8c3a12d000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:423)这就是连接池耗尽的铁证。此时redis-cli info clients中connected_clients会远高于maxclients配置值。6.4 缓存击穿的火焰图特征不是 CPU 高而是线程在 synchronized 块里排队用async-profiler生成火焰图若看到大量线程堆栈集中在com.xxx.service.ProductService.getProductDetail └─ com.xxx.cache.LocalCacheLoader.loadFromRedis └─ com.xxx.cache.RedisLock.tryLock // 自研的 SET NX EX 锁 └─ io.lettuce.core.RedisAsyncCommandsImpl.get且tryLock占比 40%说明大量请求在争抢同一个 SKU 的互斥锁正是击穿典型表现。此时要检查tryLock的超时时间是否过长我们设为 100ms超过则降级返回空。6.5 本地缓存污染的终极验证用 jmap 导出堆内存MAT 查 Object Histogram执行jmap -dump:formatb,fileheap.hprof pid用 Eclipse MAT 打开执行Histogram输入com.github.benmanes.caffeine.cache.BoundedLocalCache看Retained Heap是否异常高。若单个BoundedLocalCache占用 500MB说明weigher失效或maximumSize设得太松必须立即调整。我踩过最深的坑是在测试环境用maximumSize(10000)跑得好好的上线后因商品 POJO 加了新字段单个对象从 120KB 涨到 1.8MB10000 条直接吃掉 18GB 堆Full GC 每 3 分钟一次。后来养成了铁律——每次新增缓存字段必须用SizeOfObject.sizeOf(obj)测一遍对象大小再反推weigher公式。希望帮到你。本文还有配套的精品资源点击获取