Redis 客户端缓存失效通知与广播模式

Redis 客户端缓存一旦跨出 Redis 进程，就必须同时设计“数据怎么读”和“旧副本什么时候删”。Redis 的服务端辅助客户端缓存通过 CLIENT TRACKING 发送失效通知，常用的选择有两种：默认模式按客户端实际读过的键通知，BCAST 模式按键名前缀广播。前者通知更精准但服务端要维护键关系，后者不维护逐键关系但会把匹配前缀的变更通知给更多客户端。

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

读热点集中、键访问关系比较稳定时优先默认 Tracking；多个实例共享少量稳定前缀、又不想让 Redis 保存大量逐键关系时再考虑 BCAST。无论选哪种模式，收到失效消息都必须删除本地副本，失去通知连接时则应先清空缓存。

先看清默认 Tracking 和 BCAST 的差别

默认 Tracking 的核心是“读过什么就跟踪什么”。连接启用 Tracking 后，Redis 会记住该连接通过只读命令访问过的键；其他客户端修改这些键，Redis 就把失效消息发给可能持有副本的连接。服务端维护的关系越多，内存成本越高，但通知通常只覆盖真正被该连接读过的键。

BCAST 则换了一种取舍：Redis 不再为每个客户端保存“读过哪些键”的逐键失效表，而是根据 PREFIX 建立前缀订阅关系。只要某个匹配前缀的键被修改，订阅该前缀的客户端就会收到通知；因此服务端逐键关系更少，但客户端可能收到自己没有缓存过的键的失效消息。

按业务负载决定通知模式

不要先看命令长短再选模式，先把四个约束写下来：本地缓存覆盖的键数、键的更新频率、客户端连接数、可接受的无效通知量。只缓存少量读多写少的对象时，默认 Tracking 往往更省通知；如果应用实例很多，且缓存都围绕 user:、product: 这类稳定前缀组织，BCAST 更容易按业务域管理。

高频变化的计数器、排行榜或持续刷新的状态不适合盲目放进客户端缓存。Redis 官方建议把不适合缓存的数据放到未启用客户端缓存的独立连接上，否则失效消息开销可能抵消减少网络往返带来的收益。

还要注意客户端库能力不等于 Redis 服务端命令能力。Redis 文档列出了部分客户端对客户端缓存的支持版本；如果当前库没有完整封装 BCAST 或失效消息解析，可以直接使用底层连接能力，或者只采用库已经明确支持的模式，不要只因为服务端版本满足就假设业务代码已经具备缓存淘汰逻辑。

默认 Tracking 的最小配置

RESP3 可以在同一连接中接收普通响应和失效消息，适合客户端能够正确处理推送消息的场景。下面是命令关系示意，注释说明每个命令的职责；它不是运行输出，也不代表某个本机实例已经执行。

# 使用 RESP3 连接，让数据响应与失效推送复用一条连接
redis-cli -3

# 为当前连接打开默认 Tracking，按实际读过的键接收失效消息
CLIENT TRACKING ON

# 读取后，Redis 会把 user:1001 纳入当前连接的跟踪范围
GET user:1001

# 业务代码收到失效消息后，应删除本地缓存中的同名键
# 连接侧的缓存淘汰逻辑不由 Redis 自动完成

RESP2 不支持在同一数据连接上复用推送消息时，可以使用两条连接：一条连接订阅 __redis__:invalidate，另一条数据连接用 REDIRECT 把失效通知转给第一条连接。

# 连接 A：只负责接收失效通知，先取得自己的连接 ID
CLIENT ID

# 连接 A：订阅 Redis 为 RESP2 客户端缓存准备的失效频道
SUBSCRIBE __redis__:invalidate

# 连接 B：把当前数据连接的通知重定向到连接 A 的 ID
CLIENT TRACKING ON REDIRECT 

# 连接 B：正常读取，连接 A 负责消费并转成删除本地键的动作
GET user:1001

REDIRECT 指向的连接必须存在；如果通知连接断开，数据连接会收到重定向断开的信号或无法继续获得失效消息。连接池场景可以让多个数据连接把通知重定向到同一个专门连接，但应用必须把“通知连接生命周期”和“本地缓存生命周期”绑定起来。

BCAST 适合用前缀管理缓存域

BCAST 的命令结构是在 Tracking 后加入 BCAST 与一个或多个 PREFIX。如果不写前缀，通知范围会扩展到所有被修改的键；生产环境通常应该写窄前缀，避免把无关键变更广播到整个客户端群。

# 只接收 user: 前缀的键变更通知，减少无关失效消息
CLIENT TRACKING ON BCAST PREFIX user:

# product: 不在本连接的广播范围内，不能依赖本连接收到它的失效消息
# user:1001 即使当前连接没有先 GET，也会因前缀匹配而触发通知

前缀设计要保持清晰。Redis 文档指出，两个前缀不能覆盖重叠的键空间，例如同时注册 foo 和 foob 会产生重叠匹配；应选择一个能够覆盖业务域的前缀，而不是用很多相互包含的前缀凑范围。前缀数量较大时，服务端匹配成本也会增加。

NOLOOP、断线与缓存清空不能遗漏

如果写入连接同时把写入结果放进了本地缓存，默认情况下它可能立即收到自己的失效通知。NOLOOP 可以抑制“由当前连接修改的键”发回当前连接的通知，但在默认 Tracking 模式下，Redis 仍会因为写入而移除该键的跟踪关系。之后若还想继续接收该键的变化通知，需要再次读取它。

断线处理比命令配置更重要：只要用于接收失效消息的连接丢失，就可能有一段时间无法知道哪些本地副本已经过期。稳妥做法是把本地缓存整体清空，再等待连接恢复后的读取重新建立缓存；同时对通知连接做周期性保活，不能把 TCP 连接仍然存在误认为失效消息仍然可靠。

一个可落地的缓存对象至少应有三种状态：fresh 表示可以读取，invalidated 表示收到键通知后必须删除，flushed 表示通知链路断开后整批清空。这样重连逻辑不会把旧值悄悄恢复成“看起来正常”的状态。

上线前的选择清单

• 热点键少、读写关系明确：优先默认 Tracking，评估服务端逐键关系的内存。
• 实例多、业务域由稳定前缀划分：考虑 BCAST，并限制 PREFIX 数量和范围。
• 使用 RESP3：确认客户端能持续读取失效推送，不要只处理普通命令返回值。
• 使用 RESP2：准备独立通知连接和 REDIRECT，把它纳入连接池与重连设计。
• 通知连接断开：立即清空本地缓存，恢复后让后续读取重新建立有效副本。
• 高频写键：优先放到未启用客户端缓存的连接，避免通知成本超过缓存收益。

常见问题

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

不会。BCAST 按前缀广播，客户端可能收到自己没有缓存过的匹配键通知，因此本地淘汰处理应允许“删除不存在的键”这种幂等情况。

默认 Tracking 和 BCAST 能同时解决断线旧值吗？

不能。两种模式都依赖通知链路；链路断开后，客户端无法可靠知道遗漏了哪些修改，仍应清空相关本地缓存，恢复后重新读取。

只开启 CLIENT TRACKING 就会自动维护应用内缓存吗？

不会。Redis 只负责记录关系并发送失效消息，缓存容量、淘汰策略、消息消费和断线清空仍由客户端实现。

Redis 客户端缓存的关键决策是“通知精度和服务端状态之间如何取舍”：默认 Tracking 面向实际读键，BCAST 面向稳定前缀。先按业务负载划分缓存域，再确定协议、连接模型和断线清空策略，才能让本地缓存提速而不把一致性责任藏起来。