两级缓存的分工
多级缓存即本地缓存加 Redis：本地缓存是进程内的 LRU（Caffeine、Guava 或自研），命中时没有网络往返，纳秒到微秒级；Redis 是分布式第二层，容量大、可跨实例共享，代价是每次都要一次 RTT。两级叠加能把热点读摊到各台机器的内存上，随之而来的是一份需要主动维护一致性的副本。
基本信息
| 第一层 | 进程内缓存（Caffeine/Guava LRU），容量小、TTL 短 |
|---|---|
| 第二层 | Redis，容量大、多实例共享 |
| 失效通道 | Pub/Sub 或 Client Tracking 广播键变更 |
| 兜底机制 | 本地 TTL 设短（一般 1-5 秒） |
典型使用场景
- 配置、字典、类目这类读多写少且能容忍秒级延迟的数据
- 秒杀或大促的热点商品：用本地缓存挡掉绝大部分读请求
- Redis 抖动或短暂不可用时的降级窗口，靠本地缓存继续对外服务
- 跨机房读扩散治理：热点值不必每次跨机房取 Redis
- 带宽成本优化：热点值只在变更时通过失效通道同步一次
读取路径与失效广播
读取路径与失效广播
# 读取路径
# 1) 查本地缓存 -> 命中直接返回，零网络开销
# 2) 未命中 -> 查 Redis -> 命中则回填本地缓存
# 3) Redis 也未命中 -> 回源数据库 -> 同时写 Redis 与本地
# 写路径统一走失效广播（不要绕过）
PUBLISH cache:invalidate "user:1001"
redis-cli SUBSCRIBE cache:invalidate # 各节点收到后删除自己那份本地缓存两层缓存对照
| 维度 | 本地缓存 | Redis |
|---|---|---|
| 访问延迟 | 纳秒到微秒级 | 同机房约 0.1-1 毫秒 |
| 容量 | 受进程内存限制 | 单实例可到数十 GB |
| 一致性 | 各节点各一份，需广播失效 | 单一副本，天然一致 |
| 故障影响 | 进程重启即丢失 | 实例故障影响所有节点 |
本地 TTL 是最后一道兜底：即使某次广播丢失，数据也会在 TTL 内自动恢复一致，所以本地 TTL 不宜设长，牺牲一点命中率换一致性。
所有写路径都必须经过统一的失效广播：任何绕过广播的直写都会让部分节点长期返回旧值，而且难以复现和排查。