多级缓存需严格控制访问顺序、过期策略与一致性协同：guava用expireafterwrite（禁用refreshafterwrite），ttl设为redis的0.3～0.5倍；禁用maximumsize防oom；空值缓存写redis不写guava；guava加载后异步回写redis并重试失败。
本地缓存（Guava）和 Redis 不能简单“拼起来”就叫多级缓存——必须控制好访问顺序、过期策略、一致性边界和失效协同，否则反而引入脏数据或击穿风险。
Guava Cache 初始化时 expireAfterWrite 和 refreshAfterWrite 别混用
Guava 的 expireAfterWrite 是强制过期，到期后下一次 get 会触发 reload；而 refreshAfterWrite 是异步刷新，旧值仍可返回，适合读多写少但容忍短暂陈旧的场景。生产环境多数用前者，避免因异步线程失败导致本地缓存长期不更新。
- 高频热点 key（如首页 banner 配置）建议用
expireAfterWrite(30, TimeUnit.SECONDS)，短过期+快速回源 - 低频但计算开销大的数据（如用户权限树）可用
refreshAfterWrite(5, TimeUnit.MINUTES)，减少 DB 查询压力 - 两者不可同时设置，Guava 会抛
IllegalStateException - 别依赖
maximumSize做淘汰兜底——它只按 entry 数量淘汰，不感知内存占用，大对象可能 OOM
Redis 与 Guava 缓存 TTL 必须错开，且本地缓存不能比 Redis 更长
如果 Guava 设置了 10 分钟过期，Redis 却只设 5 分钟，那在 Redis 已失效、Guava 还没过期的 5 分钟窗口里，所有请求都从本地缓存返回陈旧数据，且无法触发回源更新（因为 Guava 没过期，不调 load 方法）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐比例：Guava TTL = Redis TTL × 0.3～0.5（例如 Redis 设 30 分钟，Guava 设 10 分钟）
- 绝对禁止 Guava TTL ≥ Redis TTL，这是多级缓存一致性的硬约束
- Redis 的 key 过期时间建议加随机偏移（如
30 * 60 + ThreadLocalRandom.current().nextInt(300)），防雪崩 - Guava 不支持动态改 TTL，所以初始化时就要定死，别想着运行时调整
缓存穿透/击穿必须在 Guava 层外拦截，Guava 本身不防并发
Guava 的 LoadingCache 在 key 未命中时，多个线程并发调用 get(key) 会各自触发 load() 方法——也就是 N 个线程同时查 DB 或 Redis，造成击穿。它不像 Caffeine 提供 refreshAfterWrite 的同步锁机制。
- 必须在 Guava 外包一层互斥逻辑：比如用 Redisson 的
RLock或 JUC 的ConcurrentHashMap.computeIfAbsent+Future包装 - 布隆过滤器（BloomFilter）要放在最外层（如网关或 service 入口），不能等请求落到 Guava 才判断——Guava 不知道 key 是否合法
- 空值缓存（cache null）必须写入 Redis，Guava 不适合存 null（
getIfPresent返回 null 无法区分“没命中”和“存了 null”） - 别在 Guava 的
CacheLoader.load()里直接写 Redis——这会让缓存写入变成串行瓶颈
Guava 本地缓存更新必须异步回写 Redis，且要处理失败重试
每次 Guava 通过 load() 加载新值后，如果同步写 Redis，会把原本微秒级的本地访问拖慢到毫秒级，失去本地缓存意义。必须解耦。
- 用线程池异步执行
redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS) - 异步失败时，需记录日志 + 上报监控，不能静默丢弃（否则 Guava 有新值，Redis 还是旧值）
- 不要用 Spring 的
@Async直接标注load()方法——事务上下文和线程绑定会导致不可预知行为 - 若业务允许，可考虑“写 Redis 失败后，主动让 Guava 对应 key 过期”，下次请求自然重新加载并再试一次
真正难的不是把 Guava 和 Redis 接上，而是厘清每一层该承担什么责任：Guava 只管“快”和“单机可用”，Redis 管“共享”和“最终一致”，中间那层协调逻辑（锁、空值、刷新、回写）才是容易出问题的地方。漏掉任意一环，多级缓存就从加速器变成故障放大器。
