REDIRECT 代收失效消息是什么
客户端缓存默认要求每个连接自己接收失效通知，连接池场景下这很浪费。CLIENT TRACKING ON REDIRECT 连接编号 可以把失效消息统一转发给指定连接，由它代收后再分发给池内其他连接；代价是这条代收连接必须专职订阅失效频道，生命周期要单独管理。
基本信息
| 命令 | CLIENT TRACKING ON REDIRECT 连接编号 |
|---|---|
| 代收方式 | 代收连接订阅失效频道并持续接收推送 |
| 适用结构 | 连接池或代理共享一份跟踪状态 |
| 配套命令 | CLIENT TRACKINGINFO 查看跟踪模式与重定向目标 |
| 风险点 | 代收连接断开后失效消息随即中断 |
典型使用场景
- 连接池共享缓存：用一条代收连接服务整个池的失效通知
- 代理层改造：代理统一维护跟踪状态，业务连接保持简单
- 订阅规范：代收连接只做订阅，不执行其他业务命令
- 重连处理：连接编号在重连后会变化，必须重新注册
- 监控：代收连接的健康状态与消息积压单独告警
- 降级预案：代收异常时退化为主动读或缩短本地缓存时间
注册与查看
注册与查看
redis-cli CLIENT ID # 获取目标连接编号
redis-cli CLIENT TRACKING ON REDIRECT 100 # 把失效消息转发给编号 100 的连接
redis-cli CLIENT TRACKINGINFO # 查看本连接的跟踪模式与重定向目标
redis-cli SUBSCRIBE __redis__:invalidate # 代收连接订阅失效频道
redis-cli CLIENT LIST # 核对代收连接的状态与订阅数
redis-cli CONFIG GET tracking-table-max-keys # 跟踪表的规模上限角色分工
| 角色 | 职责 | 注意 |
|---|---|---|
| 业务连接 | 开启跟踪并读取数据 | 不自己订阅失效频道 |
| 代收连接 | 订阅失效频道、接收推送 | 只做订阅，不承载业务命令 |
| 应用层 | 把失效消息分发到本地缓存 | 需要处理消息丢失与重连 |
| 重连之后 | 重新注册 REDIRECT 目标 | 连接编号已经变化 |
代收连接一旦断开，失效通知立刻中断，客户端可能继续读本地缓存里的旧值，所以这条连接需要独立的健康检查与告警。
跟踪表本身有上限（tracking-table-max-keys）：键基数大时被淘汰的跟踪记录会让失效通知变得不精确。