服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 面试题：为什么不用本地缓存？答：分布式系统都用 Redis。 但现实是——很多场景本地缓存仍然是刚需： 配置数据、字典数据——QPS 高但极少变更，每次走 Redis 多一跳网络 热点商品信息——Redis 也会被打爆，本地缓存兜底 计算结果缓存——复杂的统计结果，本地存一份避免重复计算 Java 生态里三大本地缓存各有拥趸： Guava Cache——老牌选手，曾经的王者 Ehcache——老牌中的老牌，功能最全 Caffeine——新生代，号称"Guava Cache 的替代品" 到底选谁？社区争论很多，但缺少实测数据支撑。 这篇文章从 6 个维度做实测对比：读写吞吐、内存占用、过期策略、淘汰算法、Spring Cache 集成、异步加载。每个维度都有压测数据，看完你心里就有答案了。 一、三巨头简介 1.1 Guava Cache 出身：Google Guava 工具库的一部分，2010 年左右推出。 定位：简单易用的进程内缓存，API 设计优雅。 特点： API 简洁，CacheBuilder 链式调用 支持 TTL、TTI、基于引用的回收 支持 CacheLo....

大促的时候，运营在首页挂了一个爆款商品。瞬间几十万用户涌进来，同一个商品详情接口被疯狂调用。Redis 里这个商品的缓存 Key 被打到单节点 QPS 上限，响应时间从 1ms 飙升到 50ms，Redis 线程池打满，带着其他 Key 的请求也一起慢了。一块热铁掉进水里，整锅水都烫了。 这就是典型的热点 Key 问题。一个 Key 太热，把 Redis 单节点打穿了。因为 Redis 是单线程处理命令的，一个慢不会拖累别的，但如果请求量超过这个单节点的处理能力上限，所有请求都得排队。 今天聊聊怎么用 Caffeine 本地缓存做二级缓存，配合过期时间抖动防止缓存雪崩。 热点 Key 为什么难搞 先搞清楚热点 Key 的问题本质。正常缓存访问是这样的： 请求 → Redis → 命中 → 返回（1ms） 热点 Key 的情况下： 1000 个并发请求 → Redis 同一个 Key │ └─ 1000 次网络 IO（即使是 Redis，单节点也有处理上限） 问题不在"数据能不能被缓存"，而在"所有请求都打到了同一个 Redis 节点上"。如果你的 Redis 是集群模式，这个热点....

缓存的三大难题 在我们的日常开发工作中，经常会遇到这样的场景： 缓存穿透：大量请求查询不存在的数据，直接击穿到数据库 缓存雪崩：缓存同时失效，导致数据库瞬间压力过大 缓存击穿：热点数据缓存失效，大量请求涌向数据库 传统的单一缓存方案往往无法同时解决这三个问题。今天我们就来聊聊如何用SpringBoot + 多级缓存构建一个全方位的缓存防护体系。 为什么选择多级缓存 相比单一缓存方案，多级缓存有以下优势： 就近访问：本地缓存最快，Redis次之，数据库最慢 故障隔离：某一级缓存故障不影响其他层级 资源优化：合理分配不同层级的缓存资源 全面防护：多层防护，抵御各种缓存攻击 解决方案思路 今天我们要解决的，就是如何用Caffeine + Redis + 空值缓存构建一个安全高效的多级缓存体系。 核心思路是： 三级缓存：本地缓存→Redis缓存→数据库 空值缓存：防止缓存穿透 随机过期：防止缓存雪崩 热点保护：防止缓存击穿 缓存架构设计 1. 本地缓存（Caffeine） @Configuration public class LocalCacheConfig { @Bean pu....

Redis作为分布式缓存的明星选手，确实为我们的系统提供了强大的性能支持。但在某些场景下，Redis反而成了性能的瓶颈： 网络延迟：每次访问Redis都需要经过网络请求，即使在内网，延迟也在1-2ms左右 序列化开销：对象需要序列化和反序列化，增加了CPU开销 连接池限制：Redis连接池有最大连接数限制，高并发下容易成为瓶颈 带宽限制：大量缓存访问可能占用网络带宽 今天，我们就来聊聊如何用Caffeine这个本地缓存神器，来解决Redis的性能瓶颈问题。