缓存框架

Redis + Caffeine 双层缓存 📖 前置阅读：本文是缓存架构的进阶级文章，假设读者已经掌握了 Redis 的基础操作和 Caffeine 本地缓存的 API。如果还不熟悉，建议先阅读： SpringBoot Redis 全操作指南 —— Redis 实战篇 Caffeine 核心与 SpringBoot 集成 —— Caffeine 入门篇 一、⚡ 问题切入：凌晨三点，Redis 挂了 凌晨三点，Redis 内存用满——大量的 TTL 同时到期 + 新一波定时任务写入，导致内存 OOM，Redis 进程被系统 kill。你的服务所有缓存请求全部报错，瞬间全部穿透到 MySQL，数据库连接池耗尽，整个系统不可用。 值班群炸了。你翻日志发现——服务启动时所有 @Cacheable 都配置了 Redis，Redis 一挂连个兜底的都没有。 Redis 是高可用的——有哨兵（Sentinel）、有集群（Cluster），官方说可用性能到 99.99%。但 99.99% 意味着一年有将近 1 小时的不可用时间。这 1 小时如果发生在双十一，后果就不是"维护了一次"，而是"事故"。 本地缓存的价值不只是"快"，更是 Redis 挂了时的最后一道防线。就算 Redis 是全宇宙最高可用的服务，网络也可能抖——交换机故障、机房间专线断掉、Kubernetes 网络策略变更——这些事情的发生概率比 Redis 自身故障高得多。 本篇要解决的问题：构建 Redis（远程）+ Caffeine（本地）双层缓存架构，把 Redis 的不可用当成"迟早会发生的事"来设计，而不是寄望于它不会发生。 📌 真实场景：数据字典——最简单的双层缓存 在进入复杂架构之前，先看一个真实项目里怎么用 Spring Cache + Caffeine + Redis 做双层缓存。不是所有场景都需要 200 行的 TieredCacheManager——有时候 3 行配置 + 1 个注解就够了。 ...

Caffeine 核心与 SpringBoot 集成 📖 前置阅读：本文假设读者已了解 Redis 基本操作和 Spring Cache 注解（@Cacheable/@CachePut/@CacheEvict）。如果还不熟悉 Redis 系列，建议先阅读 SpringBoot Redis 全操作指南。 一、⚡ 问题切入：Redis 再快也是远程调用 回顾一下，一个典型的 Redis 缓存查询是： // Redis 缓存读 User user = (User) redisTemplate.opsForValue().get("user:1001"); if (user != null) return user; // 缓存未命中，查 MySQL user = userMapper.selectById(1001L); redisTemplate.opsForValue().set("user:1001", user, 30, TimeUnit.MINUTES); return user; Redis 延迟一般在 0.5ms ~ 2ms——相比 MySQL 的 3ms ~ 10ms 已经快很多了。但这个延迟不是免费的：每次 Redis 查询都是一次网络往返（RTT）。同机房内 RTT 大约 0.1ms，跨机房可能到 2ms 甚至更久。 在高 QPS 下，这 0.5ms × 10 万次查询 = 50 秒的累计时间，还不算序列化/反序列化的 CPU 开销。而且 Redis 不是永远不会挂——网络抖动、内存满了、主从切换，任何一个都可能让 Redis 临时不可用。 ...