Redis 客户端缓存怎样使用广播失效

Redis 客户端缓存开启广播失效时，核心命令是 CLIENT TRACKING ON BCAST PREFIX ...。它不让 Redis 记录每个客户端读过的全部 key，而是让客户端声明自己关心的 key 前缀；匹配前缀的 key 被修改时，Redis 向订阅该前缀的客户端发送失效通知。

官方地址：https://redis.io/docs/latest/develop/reference/client-side-caching/

想用好 BCAST，先把客户端缓存的 key 设计成互不重叠的业务前缀，再确认失效连接确实收到了通知。前缀越宽，收到的消息越多；完全不写 PREFIX 则会把所有被修改的 key 都纳入通知范围。

规模背景：为什么要从逐 key 跟踪转向广播

Redis 的客户端缓存有两种不同的服务端取舍：普通 tracking 记录客户端可能缓存过哪些 key，修改时只通知相关客户端；BCAST 不维护这张按 key 记录的失效表，而是按前缀广播。因此，BCAST 可以减少 Redis 为每个客户端保存 key 关系的内存，但会把匹配前缀的变更通知给该前缀的所有订阅者。

如果客户端数量较多、缓存 key 的访问组合不断变化，或者服务端不希望长期维护大量 key 到客户端的关联，BCAST 更容易管理。它的代价也很明确：前缀越宽，客户端越容易收到自己没有缓存的失效消息；注册的前缀很多时，Redis 处理前缀匹配的 CPU 成本也会上升。

新架构：用 BCAST 与 PREFIX 组织失效通知

先把数据连接与接收失效通知的连接分开描述，避免把“发起查询的连接”和“接收失效消息的连接”混为一谈。下面的命令只展示配置形态，实际客户端需要把返回的通知解析成要删除的本地缓存条目。

# 为接收失效通知的连接取得客户端 ID
redis-cli CLIENT ID

# 在数据连接上启用广播模式，只关注两个业务前缀
redis-cli CLIENT TRACKING ON BCAST PREFIX user: PREFIX order:

# 数据连接读取带前缀的 key，客户端可以把返回值放入本地缓存
redis-cli GET user:42
redis-cli GET order:9001

RESP3 可以在同一连接上承载数据回复与失效 push 消息；RESP2 常见做法是用一个连接取数据、另一个连接接收通知，并通过客户端 ID 做重定向。无论采用哪种连接模型，应用都必须真正消费失效消息并删除对应的本地缓存，否则 Redis 发出了通知，应用仍可能继续返回旧值。

关键取舍：前缀重叠、空前缀与连接断线

BCAST 的 PREFIX 不是普通的标签列表，而是 key 空间的匹配边界。Redis 官方文档明确限制：两个前缀不能覆盖重叠的 key 空间。例如 foo 和 foob 都会匹配 foobar，因此不应同时注册。只保留 foo 已经足够覆盖这段空间。

# 推荐：两个业务前缀互不包含，边界更容易解释
redis-cli CLIENT TRACKING ON BCAST PREFIX user: PREFIX order:

# 反例：foo 与 foob 存在重叠，容易被 Redis 拒绝或造成设计误解
# redis-cli CLIENT TRACKING ON BCAST PREFIX foo PREFIX foob

# 不写 PREFIX 等同于空前缀，会扩大到所有被修改的 key
# redis-cli CLIENT TRACKING ON BCAST

实际设计时，先列出会进入本地缓存的 key 命名空间，再决定前缀。比如只缓存用户资料和订单摘要，可以使用 user: 与 order:；如果团队既有 user: 又有更细的 user:profile:，后者已经被前者覆盖，就不必同时注册。

没有收到通知：先查覆盖范围与连接状态

先确认发生变化的完整 key 是否以已注册 PREFIX 开头。例如监听 user: 时，修改 profile:42 不会触发该前缀的广播。再确认接收通知的连接没有断开；一旦失效连接丢失，客户端应清空本地缓存并重新建立订阅，而不是继续相信旧副本。

通知过多：收窄前缀，不要先在客户端静默丢弃

如果监听了空前缀，所有被修改的 key 都可能进入通知范围；如果用了 app: 这样的宽前缀，业务下的计数器、临时状态和高频写 key 也会被带上。优先按稳定的业务对象重新命名或拆分前缀，让 Redis 在源头缩小广播范围。

缓存仍然返回旧值：检查消息处理而非只检查 Redis

BCAST 只负责发失效消息，不替应用删除本地对象。收到通知后，客户端要按 key 删除缓存；如果采用异步处理，还要考虑通知到达与读请求之间的竞态。稳妥的策略是：读请求开始时标记加载中，收到失效通知就删除或标记过期，返回新值后只有在条目仍有效时才写回本地缓存。

上线结果：观察通知量和缓存新鲜度

• 数据连接确实执行了 CLIENT TRACKING ON BCAST，没有误用普通 tracking 或把参数发到了错误连接。
• 每个 PREFIX 都对应真实的本地缓存 key，且没有两个前缀互相包含。
• 确认省略 PREFIX 的影响：空前缀会扩大通知范围，不应把它当成“默认关闭过滤”。
• 失效连接断开时会清空本地缓存，并在重连后重新建立 tracking 配置。
• 应用会消费通知并删除本地 key；只记录通知而不清理缓存，不能解决脏读。
• 观察通知量和前缀数量，避免用过宽前缀换来不可控的客户端处理压力。

后续改进：把命名空间和断线恢复固化

BCAST 会让 Redis 为每个客户端保存访问过的 key 吗？

不会。BCAST 的设计是不维护普通 tracking 那种按客户端记录 key 的失效关系，而是维护前缀与客户端的关联；代价转移到了前缀匹配和广播消息数量。

两个 PREFIX 可以一个是另一个的开头吗？

不建议，也不应这样配置。只要两个前缀会匹配同一段 key 空间，就属于重叠；例如 foo 与 foob 会同时匹配 foobar，保留更宽的前缀即可。

客户端断线重连后，原来的本地缓存还能继续用吗？

不能直接信任。失效通知连接中断期间可能漏掉变更，重连时应清空本地缓存并重新启用 tracking，再逐步填充新的副本。