BCAST 广播追踪是什么
CLIENT TRACKING ON BCAST PREFIX user: 用前缀广播取代按键记录：服务端不再为客户端读过的每个键维护追踪记录，只要匹配前缀的键发生变更就发通知。省掉了按键跟踪表的内存与维护成本，代价是粒度变粗——前缀范围内任何键的变更都会触发失效，客户端只能整片丢弃本地缓存。
基本信息
| 命令形式 | CLIENT TRACKING ON BCAST PREFIX <前缀> |
|---|---|
| 内存代价 | 不维护按键级的追踪表 |
| 通知粒度 | 前缀内任意键变更都会通知 |
| 前缀数量 | 一条连接可以指定多个前缀，客户端需自行管理 |
| 适用场景 | 读多写少且键前缀划分清晰的业务 |
两种模式对照
| 维度 | 默认按读跟踪 | BCAST 前缀广播 |
|---|---|---|
| 内存占用 | 与唯一被读键数量成正比 | 与前缀数量相关，通常小得多 |
| 通知精度 | 精确到具体键 | 前缀范围内全部通知 |
| 客户端处理 | 按返回的键丢弃对应缓存 | 按前缀批量失效 |
| 适用场景 | 键空间大且读模式分散 | 前缀清晰、读多写少 |
示例
示例
redis-cli CLIENT TRACKING ON BCAST PREFIX user: # 单前缀广播
redis-cli CLIENT TRACKING ON BCAST PREFIX user: PREFIX order: # 多个前缀
redis-cli CLIENT TRACKINGINFO # 确认当前跟踪配置
redis-cli CLIENT TRACKING OFF
# 广播模式不使用按键级追踪表，tracking-table-max-keys 主要约束默认模式典型使用场景
- 前缀清晰的业务缓存：按业务对象前缀组织本地缓存
- 键空间极大：逐键跟踪不现实时改用广播
- 客户端希望批量失效：一次通知清掉一整组缓存
- 通知噪声评估：按真实写入频率估算前缀内的通知量
- 模式混用排查：确认不同连接各自使用的跟踪方式
前缀划分得越细通知越精准，但前缀数量也随之增加；客户端最好按前缀组织本地缓存，才能把一次通知高效映射成批量失效。
前缀范围过大时，任何一个相关键的写入都会让整片本地缓存失效，通知噪声可能把缓存收益完全抵消；上线前用真实写入频率估算通知量。