Redis CLIENT TRACKING用 BCAST 接收客户端缓存失效通知的实现方法

Redis 客户端缓存要解决的难点不是“把 GET 结果放进进程内存”，而是 Redis 中的键发生变化后，客户端能不能及时丢掉旧值。CLIENT TRACKING 的 BCAST 模式适合按业务前缀接收失效通知：Redis 不再为每个客户端记录访问过的每个键，而是维护“前缀—客户端”关系，匹配前缀的键被修改时向订阅者发送失效消息。

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

BCAST 的核心是前缀订阅，不是逐键登记

默认 Tracking 会记录“某个客户端可能缓存了哪些键”，键被修改、过期或被淘汰时只通知相关客户端。客户端数量和访问键数量都很大时，这张失效表会产生额外内存。BCAST 换了一个取舍：服务端不维护逐键清单，只维护前缀订阅关系。因此它适合键名有稳定业务命名空间的场景，例如 object:、user:、catalog:。

代价也很明确：只要 user:42 被修改，订阅 user: 的客户端都会收到通知，即使某个客户端根本没有缓存它。前缀数量过多时，服务端还要为更多前缀匹配修改操作，CPU 成本会上升。BCAST 是“少维护服务端状态、接受更多广播”的方案，不是无条件优于默认 Tracking。

用 CLIENT TRACKING 配置 BCAST 和 PREFIX

以 RESP3 单连接模型为例，客户端可以在同一连接上启用广播跟踪：

# 只接收 object: 和 user: 命名空间的失效通知
CLIENT TRACKING ON BCAST PREFIX object: PREFIX user:

# 读取的数据仍由应用决定是否写入本地缓存
GET user:42

如果不写 PREFIX，空前缀意味着所有被修改的键都可能触发通知，通常范围过大。还要注意前缀不能重叠，例如 foo 与 foob 不能同时声明，因为 foobar 会同时命中它们。设计时应选择最小但完整的命名空间，比如只保留 user:，不要再叠加一个覆盖它的短前缀。

RESP2 或连接池场景常使用两条连接：数据连接通过 REDIRECT 指向通知连接，通知连接订阅特殊入口：

# 通知连接：先取自己的连接 ID，再订阅 Redis 的失效消息入口
CLIENT ID
SUBSCRIBE __redis__:invalidate

# 数据连接：把失效消息重定向到通知连接 ID 10，并按前缀广播
CLIENT TRACKING ON BCAST REDIRECT 10 PREFIX object: PREFIX user:

这里的 Pub/Sub 入口是 RESP2 兼容方式，消息只会送到 REDIRECT 指定的连接，并不是普通频道订阅者都收到。客户端库若使用 RESP3，则应按库的 push 消息接口读取，而不要把失效消息误当作普通业务 Pub/Sub 消息。

失效消息到了以后，客户端要做什么

失效通知本身不替你修改本地缓存。客户端收到类似 __redis__:invalidate 的消息后，应取出其中的键名并删除对应条目。批量失效时消息数据可能包含多个键；执行 FLUSHDB 或 FLUSHALL 这类全量清理时，需要按客户端协议处理空值信号，通常直接清空本地缓存。

// 失效消息处理示意：消息只负责告诉本地缓存哪些键不能再用
func handleInvalidation(keys []string, localCache map[string][]byte) {
	for _, key := range keys {
		// 删除不存在的键也应视为成功，避免重复通知阻塞消费循环
		delete(localCache, key)
	}
}

数据连接和通知连接分离时，要防一个竞态：GET 的结果可能晚于失效消息到达。稳妥做法是在发出 GET 时先把本地条目标记为“读取中”；如果期间收到失效通知，就删除占位。等旧 GET 返回后，发现该键已经不在缓存映射中，就不要把旧结果重新写回去。

处理前缀、NOLOOP 与断线边界

NOLOOP 可用于避免“客户端自己修改键后又收到自己的失效通知”。它适合客户端会把自己的写入结果直接放入本地缓存的场景，但它只抑制当前写入连接的回环通知，不会替客户端解决其他连接的修改，也不代表这个键永久保持跟踪。写入后若还要继续接收后续变化，仍要按照客户端库的 Tracking 规则重新建立有效关联。

连接断开是最容易被忽略的恢复边界。通知连接失效期间，Redis 发生的写入可能不会被客户端看见，所以重连成功后不能直接沿用原缓存；应先清空本地缓存，再恢复 Tracking，并逐步重新读取。若业务不能接受这段不确定性，还要给本地条目设置较短 TTL，作为广播通知之外的第二道保护。

常见问题

BCAST 会不会只通知真正缓存过的键？

不会。它按前缀广播，客户端可能收到自己没有保存的键，这是用服务端逐键内存换取通知范围的结果。

可以同时声明 user: 和 user:profile: 吗？

不建议也通常不被允许，因为后者与前者存在重叠键空间。保留覆盖业务对象的最小前缀即可。

收到失效消息后重新 GET 就够了吗？

还不够。必须先删除旧副本，并处理通知早于 GET 返回的竞态；否则旧结果可能在失效之后被重新写回缓存。