Client Tracking 失效通知怎么配置或排查

Redis 的 Client Tracking 不发失效通知时，先检查“通知从哪条物理连接出去、由哪条连接接收”，不要一上来给本地缓存加更短的 TTL。Tracking 是连接级状态：读取缓存的连接必须开启跟踪，RESP3 要能处理同一连接上的 push；RESP2 则必须把通知重定向到仍然存活、能接收 __redis__:invalidate 的连接。

官方地址：https://redis.io/docs/latest/

先确认 Client Tracking 绑定的是哪条物理连接

Redis 默认不会替应用自动开启 Tracking。最小配置是在承载本地缓存读取的那条连接上执行 CLIENT TRACKING ON。默认模式只记录这条连接读过的 key，之后这些 key 被修改、过期或被淘汰时，Redis 才向对应连接发送失效通知。

# 示例：在“数据连接”上启用默认的按 key 跟踪
redis-cli CLIENT TRACKING ON

# 示例：只让匹配 user: 前缀的 key 进入广播通知范围
redis-cli CLIENT TRACKING ON BCAST PREFIX user:

# OPTIN 下只有紧跟 CLIENT CACHING YES 的下一次读取会被跟踪
redis-cli CLIENT TRACKING ON OPTIN
redis-cli CLIENT CACHING YES
redis-cli GET user:42

默认模式、BCAST、OPTIN 和 OPTOUT 不是可以随意叠加的“增强开关”。默认模式适合客户端只关心自己实际读过的 key；BCAST 适合按前缀接收更宽的通知，但前缀越宽，客户端收到的无关通知越多。OPTIN 忘记发送 CLIENT CACHING YES，看起来就像 Tracking 失效。

RESP2 和 RESP3 的通知连接不是一回事

RESP3 支持在数据连接上接收 Redis 的 push 消息，所以客户端需要把“普通命令回复”和“异步失效消息”分开解析。RESP2 没有这种多路复用能力，常见做法是单独建立通知连接，再用它的 client ID 配置 REDIRECT；通知连接还要订阅特殊的 __redis__:invalidate 通道。

# RESP2 示例：先取得专门通知连接的 client ID
redis-cli CLIENT ID

# 在通知连接上接收失效消息；它不是普通业务数据连接
redis-cli SUBSCRIBE __redis__:invalidate

# 在数据连接上把通知指向上一步得到的 client ID
redis-cli CLIENT TRACKING ON REDIRECT 1234

这里的 1234 只是示例 ID，不能照抄。通知连接断开后，原来的重定向关系就没有可用去处；连接池重连、拓扑切换或健康检查杀掉长连接时，都要重新取得 ID 并重新配置。另一个容易漏掉的责任是：Redis 只发送“该 key 失效了”，本地客户端仍然要删除自己的缓存条目。

先用两个连接级命令确认通知链路

排查时要拿到应用实际使用的物理连接。执行 CLIENT GETREDIR 可以知道通知有没有重定向，执行 CLIENT TRACKINGINFO 可以看到 Tracking 标志、重定向 ID 和前缀。下面的命令是诊断示意，不能在一条新开的临时连接上代替应用连接。

# 必须通过应用连接执行，检查 Tracking 的 flags、redirect 和 prefixes
redis-cli CLIENT TRACKINGINFO

# -1 表示未开启 Tracking，0 表示没有重定向，正数是目标 client ID
redis-cli CLIENT GETREDIR

如果使用 NOLOOP，当前连接修改自己的 key 时不会收到自己的失效通知；而且默认跟踪模式下该 key 的跟踪关系会被移除，后续要再次读取它，Redis 才会重新记住它。这个行为常被误判成“偶发丢通知”。

连接池里最容易踩中的四个坑

1. 借到的连接不是启用 Tracking 的连接。初始化连接 A 后，把读取请求随机发到连接 B，B 并没有跟踪状态。把 Tracking 初始化放进每条连接建立后的钩子，并记录连接 ID。
2. 把通知连接放进普通命令池。RESP2 的订阅连接应保持专用，不能被普通 GET、SET 借用；否则客户端库可能无法稳定解析两种消息。
3. 只处理 Redis 回复，不处理异步 push。RESP3 客户端必须注册失效消息回调，并在回调里按 key 删除本地条目；不能等下一次 GET 时才“顺便”处理。
4. 修改模式后没有清理旧状态。需要更换广播前缀时，先关闭再按完整前缀集合重新开启；不要以为追加一次 PREFIX 就等价于删除旧前缀。

可以把下面这张清单放进连接初始化和重连流程：协议模式已明确；每条数据连接都执行了 Tracking 配置；RESP2 有独立通知连接；通知连接存活；客户端能解析 __redis__:invalidate 或 RESP3 push；收到 key 后确实删除本地缓存。六项中任意一项缺失，先修连接生命周期，再考虑缓存淘汰策略。

相关问题

为什么 CLIENT TRACKING ON 返回 OK 仍然没有通知？

OK 只说明当前连接接受了配置，不代表应用使用的就是当前连接，也不代表客户端已经读取异步通知。继续在应用连接上核对 CLIENT TRACKINGINFO，再检查客户端的 push 或订阅回调。

Client Tracking 能不能替代本地缓存 TTL？

不能把它当成唯一保险。Tracking 负责通知客户端某个 key 需要失效，本地缓存仍应有合理 TTL、重连后的冷启动策略和通知断线时的降级方案；两者解决的是不同层面的风险。