客户端缓存与 tracking 表
CLIENT TRACKING 让服务端记住某个连接读过哪些键，键发生变化时主动推送失效消息，客户端据此丢弃本地缓存，省掉轮询与无谓的网络往返。代价在服务端：记录「谁读过哪些键」的 tracking 表本身要占内存，键数量与连接数越大开销越明显，因此有专门的表大小上限。
基本信息
| 命令 | CLIENT TRACKING ON 与 CLIENT TRACKING OFF |
|---|---|
| 跟踪模式 | 默认按实际读取记录，另有 BCAST 广播模式与 OPTIN、OPTOUT |
| 表上限 | tracking-table-max-keys 限制 tracking 表规模 |
| 状态查看 | CLIENT TRACKINGINFO 看当前连接的跟踪状态 |
| 消息通道 | 性能更好的客户端走 RESP3 推送，也可以 REDIRECT 到另一连接 |
两种跟踪方式
| 方式 | 记录内容 | 内存特征 |
|---|---|---|
| 默认模式 | 逐个记录每个连接读过的键 | 表大小与唯一键数量成正比 |
| BCAST 模式 | 按前缀广播变更，不逐键记录 | 关注前缀数量与消息量即可 |
| OPTIN 与 OPTOUT | 由 CLIENT CACHING 显式控制参与范围 | 表内容取决于客户端选择 |
| REDIRECT | 失效消息转发给指定连接 | 便于集中处理，但需要额外的消息分发逻辑 |
示例
示例
redis-cli CLIENT TRACKING ON # 开启跟踪
redis-cli CLIENT TRACKINGINFO # 查看当前连接跟踪状态
redis-cli CONFIG GET tracking-table-max-keys
redis-cli CONFIG SET tracking-table-max-keys 2000000
redis-cli CLIENT TRACKING ON BCAST PREFIX user:
redis-cli CLIENT CACHING YES # OPTIN 模式下显式开启本次跟踪典型使用场景
- 高读低写业务：本地缓存加失效通知，替代定时轮询
- 降低服务端压力：减少无谓的重复读请求
- 表规模评估：按唯一键数量估算 tracking 表的内存占用
- 排查失效风暴：客户端频繁收到失效消息时检查前缀划分与写入频率
- 协议选型：确认客户端是否支持 RESP3 推送，否则需用重定向方案
到达表上限后，服务端会淘汰 tracking 表中的键并向相关连接发送失效消息，客户端看到本地缓存被清掉属于预期降级，不是故障。
失效通知是异步的，键被修改到客户端收到消息之间存在窗口，业务要容忍短暂旧读；对强一致要求的读路径不要依赖本地缓存。