tracking-table-max-keys 是什么
客户端缓存（client-side caching）要工作，服务端得记住每个客户端读过哪些键，这张记录表的大小由 tracking-table-max-keys 控制，默认 1000000。达到上限后服务端会淘汰一部分跟踪记录，被挤出去的键不再被精确跟踪：客户端可能收不到失效通知，也可能只收到一次保守的失效消息。
基本信息
| 配置项 | tracking-table-max-keys |
|---|---|
| 默认值 | 1000000 |
| 超限行为 | 淘汰跟踪记录，相关键退化为不再精确跟踪 |
| 使用前提 | 客户端通过 CLIENT TRACKING 开启缓存跟踪（Redis 6.0 起） |
| 生效方式 | CONFIG SET 动态生效 |
典型使用场景
- 读多写少且启用客户端缓存的业务：跟踪表规模随被读键的基数增长
- 缓存旧读敏感的场景：宁可让客户端多兜底一次校验，也不把上限设得过大
- 内存预算：跟踪表本身占内存，与数据区共享同一份 maxmemory 额度
- 键基数不受控的实例：先收敛使用方式（限制前缀），再谈调大上限
- 一致性排障：客户端抱怨读到旧值时，先确认跟踪记录是否已被挤出
查看与设置
查看与设置
redis-cli CONFIG GET tracking-table-max-keys # 当前上限
redis-cli CONFIG SET tracking-table-max-keys 2000000 # 调大前先评估跟踪表内存
redis-cli CLIENT TRACKINGINFO # 当前连接的跟踪模式与重定向目标
redis-cli CLIENT TRACKING ON BCAST PREFIX cache: # 广播模式按前缀推送，不逐键记录
redis-cli INFO clients # 跟踪相关计数，字段随版本变化
redis-cli MEMORY STATS # 观察跟踪表在内存分布里的占比跟踪模式与压力
| 模式 | 记录量 | 适用场景 |
|---|---|---|
| 默认逐键跟踪 | 随被读键的数量增长 | 读的键范围可控的缓存 |
| BCAST 广播模式 | 不逐键记录，按前缀推送失效 | 键前缀清晰、写入频繁的缓存 |
| OPTIN 模式 | 只跟踪显式声明的键 | 大部分读不需要缓存的业务 |
| OPTOUT 模式 | 默认跟踪、可显式排除 | 读基本都要缓存的业务 |
| 超过上限 | 记录被淘汰，通知不再精确 | 调大上限或收敛使用方式 |
跟踪表是服务端为客户端缓存付出的代价：记录越多失效越精确，内存也越高。上限只是兜底，真正决定记录量的是业务到底读了哪些键。
把上限调到极大而不控制读取范围，跟踪表会与数据区抢内存，最终仍然触发淘汰，客户端的一致性预期落空。