分层缓存要算的账
多层缓存把进程内内存与 Redis 组合起来，降低延迟与网络流量。代价是一致性维护：本地副本存在时间窗口，数据可能短时陈旧。落地要点是本地层设短 TTL 或依赖失效通知，并把内存预算按层分配清楚，而不是让本地缓存无声膨胀。
基本信息
| 收益 | 降低延迟、减少流量 |
|---|---|
| 成本 | 一致性维护的复杂度 |
| 配套机制 | 短 TTL 或失效通知 |
| 前提 | 业务能接受短暂旧读 |
| 服务端支持 | CLIENT TRACKING，Redis 6.0+ |
典型使用场景
- 读多写少、延迟敏感的热点配置类数据
- 跨机房访问 Redis 代价高，用本地层减少往返
- 单实例高频读取同一批键，避免重复网络开销
- 与客户端缓存跟踪配合，实现主动失效
- 内存预算划分：本地层容量与 Redis 容量的分工
服务端跟踪相关命令
服务端跟踪相关命令
redis-cli CLIENT TRACKING ON # 开启客户端缓存跟踪（6.0+）
redis-cli CLIENT TRACKINGINFO # 查看当前连接的跟踪状态与模式
redis-cli CLIENT TRACKING ON REDIRECT 1 # 把失效通知重定向到另一条连接（示意）
redis-cli CONFIG GET maxmemory # Redis 侧的容量预算
redis-cli INFO clients | grep -E 'connected_clients'
# 本地缓存侧：进程内维护热数据副本，配合短 TTL 或失效回调清理层级与一致性成本
| 层级 | 命中表现 | 一致性成本 |
|---|---|---|
| 仅进程内本地缓存 | 单机最快 | 多实例副本之间可能不一致 |
| 本地加 Redis 两级 | 命中率高 | 需要失效通道或短 TTL |
| 仅 Redis | 无本地不一致问题 | 延迟与流量都更高 |
| 带失效通知的本地缓存 | 命中率与新鲜度兼顾 | 需维护通知通道与常驻连接 |
客户端缓存跟踪有两种模式：默认模式由服务端记录该连接读过的键，BCAST 模式改为按前缀广播失效消息、不需要服务端逐键记录，内存开销更可控，但会收到较多无用通知。
本地缓存 TTL 设得过长，回源数据会长期陈旧；强一致要求的数据不要放进本地层，因为失效通知本身是异步投递的。
本地缓存必须设容量上限与淘汰策略。没有上限的进程内缓存会把业务进程自己的内存吃满，影响面比 Redis 侧的问题更大。