直接选 Caffeine。它在高并发读写下命中率更稳、GC 压力更小，且原生支持异步刷新和权重淘汰，而 Guava Cache 的 refreshAfterWrite 是同步阻塞的，易拖慢请求链路。
本地缓存该用 Caffeine 还是 Guava Cache？
直接选 Caffeine。它在高并发读写下命中率更稳、GC 压力更小，且原生支持异步刷新和权重淘汰——这对多级缓存的“预热+降级”很关键。Guava Cache 的 refreshAfterWrite 是同步阻塞的，一旦后端 Redis 集群延迟升高，本地缓存线程会卡住，拖慢整个请求链路。
实操建议：
- 用
Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES)控制内存水位，避免 OOM - 配合
refreshAfterWrite(2, TimeUnit.MINUTES)实现后台异步加载，但必须搭配CacheLoader.asyncReload+ 自定义 fallback（比如返回旧值或 null） - 不要开启
recordStats()上生产，统计开销在 QPS > 5k 时明显可见
Redis 集群 key 分布不均导致热点穿透怎么办？
集群模式下，单个 key 的 hash slot 固定，如果业务大量访问 user:10086:profile 这类低基数 key，对应节点 CPU 和连接数会飙升，而其他节点空闲——这不是缓存没命中的问题，是数据倾斜本身触发了 Redis 节点过载。
解决思路不是加机器，而是改 key 结构：
- 对高频读的实体 ID 做散列扰动，例如把
user:10086:profile改成user:10086_abc123:profile（abc123是 MD5(10086) 前 6 位），让相同用户的不同请求落到不同 slot - 对聚合类 key（如
dashboard:summary:202405）强制加随机后缀，用dashboard:summary:202405:shard{0..3}拆成 4 个 key，应用层合并结果 - 禁用
redis-cli --cluster check的自动 rebalance，它只看 slot 数量，不看实际流量，盲目迁移可能加剧热点
本地缓存与 Redis 集群如何协同失效？
不能依赖 TTL 自然过期：Caffeine 默认过期是惰性删除，Redis 集群的 key 过期是被动清理，两者时间不同步会导致脏读。必须引入显式失效机制。
推荐方案是「写时双删 + 版本号校验」：
- 更新 DB 后，先删本地缓存（
cache.invalidate(key)），再删 Redis 中的 key（DEL user:10086:profile），最后写入新值到 Redis 并带上版本号字段（如"v": 123） - 读取时，若本地缓存 miss，则从 Redis 读，并比对当前版本号是否高于本地缓存中已存的版本（如有）；若低于，主动丢弃并 reload
- 用 Redis Pub/Sub 或单独 topic（如 Kafka）广播删除指令，解决多实例本地缓存一致性问题；但注意 Pub/Sub 不保证送达，需搭配定时全量 reload 作为兜底
为什么加了本地缓存，P99 延迟反而上升了？
常见原因是本地缓存未做容量隔离，一个大 key（比如序列化后 2MB 的用户权限树）被加载进 Caffeine，挤出了几百个高频小 key，造成后续大量回源，Redis 集群瞬间被打满。更隐蔽的是 GC：频繁分配大对象触发老年代晋升，STW 时间拉长。
排查和修复要点：
- 在
CacheLoader中加 size 校验，对反序列化后 > 128KB 的 value 直接拒绝缓存，打日志告警 - 给 Caffeine 配置
weigher，按字节估算权重：weigher((k, v) -> ((byte[])v).length)，而非默认的 count-based 淘汰 - 禁止在本地缓存中存原始 JSON 字符串或未压缩的 byte[]，统一走
Protobuf序列化 +Snappy压缩，体积通常能压到 1/3
多级缓存最难的不是怎么搭，是怎么让两级缓存的生命周期、容量边界和错误恢复行为真正对齐。很多团队卡在“本地缓存看起来生效了，但线上毛刺不断”，往往是因为漏掉了版本号校验或大对象保护这两环。
