客户端缓存（CLIENT TRACKING）是什么
Redis 6.0 引入的服务端辅助客户端缓存机制：客户端开启 TRACKING 后，服务端记录它读过哪些键，一旦这些键被其他客户端修改，就通过失效通知告知该连接，客户端据此删除本地缓存副本。默认模式精确记录每个 key（内存开销随 key 数与连接数增长），BCAST 模式不记单键而按前缀广播失效，内存开销小但通知更多。
基本信息
| 适用版本 | Redis 6.0+；失效消息需要 RESP3 或 REDIRECT 转 Pub/Sub |
|---|---|
| 默认模式 | 服务端记录本连接读过的 key，变化时逐 key 通知 |
| BCAST 模式 | CLIENT TRACKING ON BCAST PREFIX <前缀>，按前缀广播 |
| 查看状态 | CLIENT TRACKINGINFO |
| 重连行为 | tracking 状态不保留，重连后需重新开启并重建本地缓存 |
| 内存开销 | 默认模式需为每个客户端维护读过的 key 列表 |
典型使用场景
- 本地缓存配合 Redis 做二级缓存：把热点数据放到进程内存
- 读多写少的配置类数据：本地缓存命中率高、失效通知少
- 多语言服务共享失效通道：用 RESP3 push 或 REDIRECT 到 Pub/Sub
- 降低网络往返：把高频读从 Redis 移到应用进程内
- 大集群场景：用 BCAST + 前缀把失效通知按业务域划分
默认模式与 BCAST 模式
默认模式与 BCAST 模式
# 默认模式：服务端记住「本连接读过」的 key，变化时逐 key 通知
CLIENT TRACKING ON
GET user:1001
# 其他客户端 SET user:1001 后，本连接收到失效消息：
# >2 invalidate
# user:1001
# BCAST：不记单个 key，按前缀广播失效（内存开销小，通知更多）
CLIENT TRACKING ON BCAST PREFIX user:
# 查看与关闭
CLIENT TRACKINGINFO
CLIENT TRACKING OFF两种模式对照
| 维度 | 默认模式 | BCAST 模式 |
|---|---|---|
| 服务端记录 | 逐 key 记录读过的内容 | 只记前缀，不记具体 key |
| 内存开销 | 随 key 数与连接数增长 | 与 key 数无关，开销小 |
| 通知量 | 精准，命中时才通知 | 按前缀广播，通知更多 |
| 适用场景 | 热点 key 集中、客户端少 | 客户端多、key 分布广 |
| 重连处理 | 状态丢失，需重新开启 | 同样需要重新开启 |
默认模式下服务端要为每个客户端维护「读过的 key」表：连接多、key 分布广时内存开销明显，生产上常用采样读取、限制本地缓存范围，或改用 BCAST 按前缀划分来控制。
不要把失效通知当成必然送达：网络中断、连接重连、客户端处理延迟都可能让本地副本过期。本地缓存必须带 TTL 兜底，并把 tracking 状态的重建写入连接初始化流程。