Redis 客户端缓存 Tracking 模式怎么选择

Redis 客户端缓存 Tracking 模式的选择，核心不是把 OPTIN、OPTOUT 和 BCAST 当成三种互斥方案，而是先回答两个问题：Redis 是否应该记住“哪个客户端读过哪个 key”，以及业务是否能用稳定前缀描述要缓存的 key。单个应用实例只缓存自己频繁读到的少量 key，优先使用默认 Tracking；多个客户端共同关心一组可预测前缀，优先考虑 BCAST PREFIX。OPTIN 和 OPTOUT 再用于收窄默认模式下的读取范围。

官方文档：https://redis.io/docs/latest/develop/clients/client-side-caching/

先用访问形态选择默认 Tracking 还是 BCAST

默认 Tracking 开启后，Redis 会记录当前连接读取过的 key；这些 key 被写入时，Redis 向相关客户端发失效通知。它适合“每个实例访问的热点集合不同，但缓存命中率较高”的场景。代价是服务端要保存客户端与 key 的关系，读取范围越大，失效消息也可能越多。

BCAST 不再为每个客户端保存已读取 key，而是订阅一个或多个前缀。只要匹配前缀的 key 被修改，订阅者就会收到通知。它更适合多实例都关心 user:、catalog: 这类稳定命名空间的情况，但通知可能包含当前实例没有缓存的 key。没有 PREFIX 时会扩大到全部 key，通常不应直接用于大型共享实例。

默认模式下用 OPTIN 或 OPTOUT 控制缓存边界

默认 Tracking 会把只读命令涉及的 key 视为可能被缓存。若业务只缓存商品详情、租户配置等少量结果，使用 OPTIN 更安全：先发送 CLIENT CACHING YES，紧接着执行读取命令。相反，如果绝大多数读取都要缓存，只有报表、随机读取或大对象不适合缓存，可以使用 OPTOUT，在例外读取前发送 CLIENT CACHING NO。

# OPTIN：只让紧随其后的这次读取进入 Tracking
redis-cli CLIENT TRACKING ON OPTIN
redis-cli CLIENT CACHING YES
redis-cli GET product:42

# OPTOUT：默认跟踪读取，明确排除一次低价值读取
redis-cli CLIENT TRACKING ON OPTOUT
redis-cli CLIENT CACHING NO
redis-cli GET report:daily:2026-10-04

CLIENT CACHING YES/NO 只影响连接上的下一条命令；事务和脚本有自己的边界，不能把它当成全局开关。若采用 BCAST，重点是前缀规划，不要用 OPTIN/OPTOUT 掩盖过宽的广播范围。

把连接、前缀和重连行为一起配置

RESP3 可以在同一连接接收失效消息；RESP2 通常需要用 REDIRECT 把通知转到另一条连接。通知连接断开时，客户端需要按库的实现重新建立跟踪关系。Redis 官方文档还说明，连接断开时客户端本地缓存会被清空，因此连接池不能只在启动时配置一次就不管。

# BCAST：只广播 user: 命名空间，避免订阅全部 key
redis-cli CLIENT TRACKING ON BCAST PREFIX user:

# 检查当前连接的模式、重定向和前缀
redis-cli CLIENT TRACKINGINFO

BCAST 的前缀要按业务边界设计，例如使用 user: 而不是同时声明重叠的 u 与 user:。如果 key 命名无法稳定归类、前缀数量过多，默认 Tracking 往往更容易控制。NOLOOP 只是不把当前连接自己的修改通知回来；它不会替你重新建立该 key 的跟踪关系，写后仍要重新读取才能继续跟踪。

用四项检查确认选择没有越界

1. 看命中：同一连接重复读取热点 key 时，确认客户端库确实从本地缓存返回，而不是只打开了 Redis 端 Tracking。
2. 看失效：另一个连接修改相同 key，确认本地副本被删除或标记失效；BCAST 则确认前缀匹配的变化能到达所有订阅者。
3. 看状态：通过 CLIENT TRACKINGINFO 检查 on、bcast、optin/optout、redirect 和 prefixes。
4. 看恢复：主动断开一条连接并重连，确认客户端清理旧缓存、重新开启 Tracking，并且没有把旧连接的通知当作有效状态。

常见问题

OPTIN 和 BCAST 可以同时使用吗？

可以从命令语义上组合，但它们解决的是不同层次的问题：BCAST 决定通知按前缀广播，OPTIN 决定读取是否进入跟踪。除非客户端库明确支持并正确处理组合状态，否则先选清晰的单一边界，通常更容易排查。

客户端支持 Tracking 命令就等于支持客户端缓存吗？

不等于。客户端还必须维护本地缓存、接收失效消息、处理连接重建和淘汰；官方文档列出的客户端支持版本也可能随库版本变化，应以实际客户端文档为准。

什么时候不该使用客户端缓存？

数据更新极其频繁、读取结果非确定、单实例本地内存很小，或业务无法接受短暂的本地副本时，不要仅因网络往返减少就启用 Tracking。