Redis CLIENT TRACKING 怎么验收：失效通知、BCAST 与 NOLOOP 边界

应用把热门用户资料放进进程内存后，Redis 的网络读取开销会下降不少，但“本地缓存的值什么时候该失效”必须有明确可验证的校验方法。Redis 6.0 起提供服务端辅助的客户端缓存能力：连接读取过的键会被 Redis 单独记录，其他连接改写这些键时会主动推送失效通知。真正容易踩坑的地方，不是简单把 CLIENT TRACKING 开关打开，而是通知接收链路、前缀匹配范围和自写入的边界逻辑没有做全量验收。

先确认失效通知链路是否真的成立

先准备两个独立的 Redis 连接：连接 A 负责读取业务键并接收失效通知，连接 B 只做键的改写操作。测试用的键名直接对齐业务侧的缓存命名规则，用 user:1001 命名，这样验收结果可以直接和线上业务缓存逻辑对应上。生产环境不要只确认 A 连接执行 CLIENT TRACKING 返回了 OK 就认为配置生效，还要实际观察 A 连接是否真的收到包含目标键的失效推送消息。

# 连接 A：使用 RESP3，并开启当前连接的 tracking
> HELLO 3
> CLIENT TRACKING ON
OK
> GET user:1001
"Alice"

# 连接 B：改写同一个键
> SET user:1001 "Flora"
OK

# 连接 A 应看到 PUSH 失效消息，其中带有 user:1001
> 1) "invalidate"
   2) 1) "user:1001"

这条链路有三个必过检查点：连接 A 必须在连接 B 修改之前读过目标键；连接 B 的修改操作必须发生在 A 读取之后；连接 A 必须使用支持 RESP3 协议、能接收 PUSH 消息的客户端。如果 A 只收到普通命令的响应、没拿到失效消息，先别急着判定 Redis 没发通知，很多客户端会把 PUSH 事件放在独立回调或者后台读取循环里处理，默认不会和命令响应一起返回。

用 TRACKINGINFO 快速判断配置状态

失效通知没按预期出现时，先直接查询当前连接的跟踪状态，不需要额外搭建 Pub/Sub 链路排查。CLIENT TRACKINGINFO 可以直接返回当前连接的跟踪标志、重定向连接 ID 和已配置的前缀列表，用来确认配置命令实际作用到了哪个连接上。

> CLIENT TRACKINGINFO
1# "flags"
2) 1) "on"
   2) "noloop"
3) "redirect"
4) (integer) 0
5) "prefixes"
6) (empty array)

常见的状态判断可以压缩成下面这张表：

普通逐键模式会在 Redis 侧维护“哪个连接读过哪个键”的映射关系，跟踪的键和客户端数量变多后，会明显增加服务端的内存压力。客户端缓存只适合高频读取、变动频率低的小部分热数据，频繁变化的全局计数器这类场景不适合直接接入这套链路。

BCAST 与 PREFIX：用通知范围换服务端内存开销

如果客户端侧没法自己维护逐键的跟踪关系，或者希望按业务命名空间统一接收键变化事件，可以切换到广播模式：

> CLIENT TRACKING ON BCAST PREFIX user:
OK
> GET user:1001
"Alice"

# B 连接改 user:1001，A 收到通知
> SET user:1001 "Flora"
OK
> 1) "invalidate"
   2) 1) "user:1001"

# B 连接改 order:9001，A 不应因 PREFIX user: 收到通知
> SET order:9001 "paid"
OK

BCAST 不再为每个客户端保存单独的逐键跟踪映射，适合边界明确的前缀空间；代价是所有命中配置前缀的键修改，都会推送给所有订阅该前缀的客户端。前缀不要随意叠加配置，重叠的前缀会让通知逻辑的边界变得非常模糊。验收时至少要做一次命中前缀的键修改、一次未命中前缀的键修改，避免只验证出广播开关正常返回 OK。

NOLOOP：自写入不通知，但跟踪关系会被移除

应用同时读写同一份本地缓存数据时，经常不希望自己写入操作触发的回环通知立刻把刚更新完的本地缓存删掉，这时候可以加 NOLOOP 参数：

# A 连接开启 NOLOOP
> CLIENT TRACKING ON NOLOOP
OK
> GET user:1001
"Alice"
> SET user:1001 "Flora"
OK
# A 不收到自己这次 SET 的失效通知

# 但下一次其他连接修改前，A 要重新 GET 让 Redis 再次跟踪该键
> GET user:1001
"Flora"

这里最容易被忽略的就是第二个逻辑点。GET 只是做通知抑制，不会保留本连接对该键的跟踪关系；本连接执行写入操作时，Redis 仍会把这个键从跟踪失效表中移除。如果后续还要接收其他连接发起的修改通知，写入完成后必须重新读取一次目标键。

连接断开时的回滚与告警确认

失效通知连接断开后，本地缓存里的存量数据就不能再当成可信数据用。安全的回滚动作是立刻清空本地全量缓存，重建通知连接，再逐步回填热点键。即使通知连接没有断开，也建议给每个本地缓存条目设置最大 TTL，作为通知链路异常时的兜底保护。

• 通知连接收到 broken_redirect 或者心跳检测失败：直接清空全量本地缓存。
• 重连成功后：重新开启 CLIENT TRACKING 配置，先回填少量核心热点键。
• 监控侧：记录失效消息接收数量、通知连接重连次数、本地缓存命中率和数据回填延迟。
• 上线前：同时验证前缀命中、前缀未命中、自写入抑制通知、写入后重新读取这四种核心状态。

常见问题

Redis CLIENT TRACKING 是从哪个版本开始的？

Redis 官方命令文档标注 CLIENT TRACKING 从 Redis 6.0.0 开始提供，CLIENT TRACKINGINFO 从 6.2.0 开始提供。实际落地时还要确认客户端库是否完整支持 RESP3 协议和 PUSH 事件的处理逻辑。

BCAST 会不会让 Redis 记录更多键？

BCAST 不使用普通模式的逐键失效表，所有通知都按前缀匹配触发；它会把原来逐键映射的成本，转移到前缀匹配的计算量和通知下发的数量上。

为什么开启 NOLOOP 后后续其他连接的修改也收不到通知？

因为本连接的写入动作会移除该键对应的跟踪关系，NOLOOP 只是不发送本次自写入触发的回环消息。写入完成后重新读取一次目标键，才能重新建立跟踪关系，后续其他连接的修改通知才能正常收到。

失效连接重连后能继续使用原来的本地缓存吗？

不建议这么做。通知链路中断期间很可能已经漏掉了部分键的修改事件，重连后应该先清空全量本地缓存，再重新读取数据逐步回填。

验收结论

Redis 客户端缓存的验收不应停留在“执行 CLIENT TRACKING 返回 OK”这个表层。最小验收闭环是：先读取目标键、再从另一个连接修改这个键、确认收到对应的失效消息；随后分别测试 BCAST 模式下的前缀命中与忽略逻辑、NOLOOP 模式下写入后的重新读取逻辑，并用 TRACKINGINFO 留存各阶段的连接状态。只要把连接断开后的清空和重建逻辑写进故障回滚路径，本地缓存就不会因为一次通知丢失而长期返回旧值。