写在前面初学的时候我们的认知是线性的先学 MySQL知道它是最终数据归宿然后学 Redis知道它是高性能分布式缓存再后来学 Caffeine听说它是“本地缓存之王”能扛超高并发。但在实际项目中我经常陷入一个困惑既然 Redis 已经很快了为什么还要加一层 Caffeine很多时候感觉 Caffeine 很多余——命中率不高、数据不一致、代码变复杂。直到我遇到一个 QPS 破万、热点数据极集中的场景才发现 Caffeine 的价值它能把 Redis 的网络开销和序列化开销都省掉让响应时间从 5ms 降到 0.1ms 级别。这篇笔记我想把 MySQL、Redis、Caffeine 放在一起对比它们各自解决什么问题什么时候值得用 Caffeine什么时候用 Redis 就够了以及如何优雅地配合使用多级缓存。1️⃣ 三种数据源的定位形象比喻MySQL 仓库东西最全但取货慢Redis 区域中转站离多个工厂服务实例都近但取货仍有交通时间Caffeine 工厂里的工具台随手可取但每个工厂自己有一套可能不统一2️⃣ 核心区别对比3️⃣ 为什么感觉 Caffeine 很多余很多项目引入 Caffeine 后发现收益不大甚至带来麻烦。常见原因场景A并发量不高QPS 1000Redis 单机能轻松抗住延迟也在可接受范围1~2ms加 Caffeine 后代码复杂度增加还要处理缓存一致性问题结论此时 Caffeine 确实多余。场景B热点数据分散命中率低Caffeine 是本地缓存每个服务实例独立。如果热点数据随机分布每个实例的缓存命中率很低比如只有20%大部分请求还是打到 Redis结论Caffeine 只适合“二八定律”极其明显的场景20%的数据承担80%的请求场景C数据更新频繁一致性要求高比如库存、余额。用 Caffeine 缓存后一旦数据变更需要通知所有实例失效缓存例如用 Redis Pub/Sub 或消息队列实现复杂且容易出错结论频繁更新的数据不要放 Caffeine场景D项目已经用了 Redis且响应时间已满足业务需求优化要适度。如果 Redis 已经够快没必要为了“极致性能”引入 Caffeine结论过度优化是万恶之源4️⃣ 什么时候该用 CaffeineCaffeine 不是银弹但在以下场景能发挥巨大价值5️⃣ 多级缓存配合方案Caffeine → Redis → MySQL最经典的架构是多级缓存请求优先走 Caffeine未命中走 Redis再未命中走 MySQL并将结果逐层回填。请求 → Caffeine (L1) → 未命中 → Redis (L2) → 未命中 → MySQL (L3) ↑ 回填 ↑ 回填 ↑ 回填伪代码示例使用 Spring Cache 自定义实现public Object getProduct(Long id) { // 1. 查 Caffeine Object cached caffeineCache.get(id); if (cached ! null) return cached; // 2. 查 Redis cached redisTemplate.opsForValue().get(key); if (cached ! null) { caffeineCache.put(id, cached); return cached; } // 3. 查 MySQL Object dbData productMapper.selectById(id); if (dbData ! null) { redisTemplate.opsForValue().set(key, dbData, 30, TimeUnit.MINUTES); caffeineCache.put(id, dbData); } return dbData; }更优雅的方式使用 Spring Cache 的Caching或二级缓存框架如 JetCache、Alibaba JetCache声明式配置多级缓存。6️⃣ 更好的实现方案不手写用框架如果你觉得手写多级缓存又臭又长可以考虑以下方案方案ASpring Cache 多 CacheManager定义两个CacheManagercaffeineCacheManager和redisCacheManager在Cacheable中指定cacheManager或者用Caching组合缺点无法自动联动Caffeine 未命中后自动查 Redis需要自己写逻辑方案BJetCache阿里开源Cached(nameproduct, expire 3600, cacheType CacheType.BOTH, localLimit 100, localExpire 60) public Product getProduct(long id) { return productMapper.selectById(id); }CacheType.BOTH表示本地远程两级缓存自动处理未命中回填支持自动刷新、异步加载、拦截器方案CCaffeine Redis 手动封装封装一个MultiLevelCache类内部逻辑统一适合不想引入额外依赖的项目个人推荐新项目直接用JetCache或Spring Cache 自定义组合不要重复造轮子。7️⃣ 避坑指南8️⃣ 总结一张图看懂怎么选QPS 1000 且 数据一致性要求高 → 直连 MySQL Redis可选 QPS 1000~1w 且 可接受 Redis 延迟 → Redis 单层缓存 QPS 1w 且 热点数据高度集中 → Caffeine Redis 多级缓存 数据极少变化且计算代价高 → Caffeine 本地缓存即可无需 Redis 数据更新频繁或需要跨实例实时同步 → 只用 Redis不要用 Caffeine一句话Caffeine 是用来把 Redis 的延迟从毫秒级降到微秒级的“加速器”只在超高并发极热点的场景下有价值普通项目用 Redis 足够不要为了“技术栈完整”而引入复杂性。 写在最后回到最初的问题为什么感觉 Caffeine 很多余因为大多数项目的并发量和热点集中度还没到需要它的程度。Caffeine 不是银弹它是一个极致场景的优化工具。就像你不会为了偶尔搬一次家而买一辆卡车一样技术选型要匹配真实需求。如果你正在做一个高并发项目并且发现 Redis 的响应时间已经无法满足比如超过5ms或者 Redis 的网络开销成为瓶颈不妨试试 Caffeine Redis 的多级缓存方案。但请记住多一级缓存多一分复杂度多一分一致性风险。下一篇我计划写一篇关于缓存一致性的终极方案深入对比 Canal、双写、消息队列等方案敬请期待