Redis 客户端缓存怎么做：Tracking、OPTIN 与失效边界

线上接口的 Redis 命中率哪怕已经做得很高，首页这类场景的热点数据还是免不了在应用进程里反复做反序列化、反复走一次网络IO。把小部分高频访问的结果直接存到应用本地内存里，能直接省掉一次跨网络请求，不过这时候核心难点就不再是怎么把数据读得更快，而是怎么准确定位本地副本的过期删除边界。Redis 的 Tracking 正是为这个边界提供服务端侧的协助：客户端读取过某个 key 后，其他连接修改它，Redis 会主动发出失效通知。

Redis Tracking 改变了哪一条缓存规则

传统方案通常把写入后的通知逻辑交给应用自行维护：每次修改 user:42，写入方还要往消息频道发布一条“删掉 user:42”的事件。Redis Tracking 把 key 和客户端的关联关系交给服务端统一维护，客户端只需要打开跟踪开关、保存本地值，再正确处理服务端发来的失效消息就可以。

最小的协议执行路径可以简化为四步：

1. 连接使用 RESP3 协议，并发送 CLIENT TRACKING ON。
2. 客户端读取 user:42，Redis 就会把这条连接标记为可能缓存过该 key。
3. 另一条连接执行 SET user:42 ...、删除或者触发 key 被淘汰。
4. 原连接收到 INVALIDATE，删除本地存的 user:42，下一次读取再回源到 Redis。

这里说的“可能缓存过”非常关键：Redis 只负责保障一致性边界，它不知道客户端本地的 LRU 淘汰策略有没有真的把这条数据留下来。所以客户端处理失效通知的时候，就算要删除的 key 在本地缓存里不存在，也应该把这个操作当成安全逻辑正常走完，不需要额外抛出异常。

默认模式和 OPTIN，差别在记录范围

默认模式下，所有只读命令触达过的 key 都会被纳入跟踪范围。它适合本地缓存策略本身就愿意接纳大量新对象的客户端，但如果长连接数量多、读取的 key 分布很散，Redis 就需要维护非常多客户端和 key 的关联关系，也可能推送不少本地根本没保存的失效通知。

如果你只想缓存首页的少数几个热点对象，就可以启用 OPTIN 模式：

CLIENT TRACKING ON REDIRECT 9001 OPTIN
CLIENT CACHING YES
GET user:42

CLIENT CACHING YES 只会影响紧随其后的那一次读取；客户端明确告诉 Redis“这次返回的结果我要放进本地缓存”，Redis 才会为这次读取建立跟踪关系。虽然多了一次额外的协议动作，却能把服务端的记录范围严格控制在真正需要被客户端缓存的 key 上。

失效通知不是普通 Pub/Sub，处理顺序不能反

客户端收到 Redis 推送的失效消息后，第一个动作就应该是从本地缓存里删掉对应 key。不要先把本地存的旧值直接返回给请求，再异步处理失效通知；也不要收到失效消息只打日志不做清理。不然下一次请求还是可能命中已经被其他连接修改过的过期内容。

func onInvalidate(keys []string) {
    for _, key := range keys {
        localCache.Delete(key)
    }
}

func getUser(ctx context.Context, key string) (User, error) {
    if value, ok := localCache.Get(key); ok {
        return value.(User), nil
    }
    value, err := redisConn.Get(ctx, key).Result()
    if err != nil {
        return User{}, err
    }
    localCache.Set(key, decodeUser(value))
    return decodeUser(value), nil
}

这段示例只用来表达处理顺序，你实际使用的 Redis Go 客户端有没有暴露 RESP3 推送消息接口、怎么单独隔离通知连接，要以对应版本的官方文档为准。通知连接阻塞、断线，或者被连接池错误复用的时候，本地缓存都要按照“无法确认数据新鲜度”的逻辑来处理。

重连、写后读取与 NOLOOP 的兼容边界

Tracking 的关联关系是完全绑定在连接生命周期上的。连接断开之后，客户端本地就算还留着之前缓存的值，新的连接也不会继续受 Redis 的跟踪保护；稳妥的处理方式是清空受影响的本地缓存分区，重新开启 Tracking 之后，再从服务端拉取数据。如果客户端支持通知恢复能力，也要等确认跟踪关系全部恢复完成之后，才重新开放本地缓存的命中入口。

写入路径还有个很常见的误区：同一客户端写完 key 之后立刻把新值放进本地缓存，默认 Tracking 可能又会把这次写入判定为需要触发失效的变化。NOLOOP 可以抑制发送给写入连接自身的失效通知，但它不会自动帮客户端跳过重建跟踪关系的流程。写完之后再主动读一次，仍然是最容易验证一致性的方案。

什么时候应该考虑广播模式

广播模式通过 BCAST 和 PREFIX 按照 key 前缀发送失效通知，不需要逐个记录“哪个客户端读过哪个 key”。它能省下服务端大量逐 key 存储关联关系的内存空间，不过所有订阅了 user: 的客户端，都有可能收到这个前缀下和自己无关的其他 key 的失效消息。

上线前用四条路径验证缓存边界

1. 读路径：读取一个允许被缓存的 key，确认本地命中之后不会再向 Redis 发起重复请求。
2. 写路径：从另一条独立连接修改、删除或者触发 key 过期，确认失效通知到达之后本地的副本已经被清理。
3. 断线路径：主动断开通知连接，确认客户端不会继续把旧值当成新鲜数据返回给业务请求。
4. 范围路径：在 OPTIN 模式下读取没有标记要缓存的 key，确认它不会意外进入服务端的跟踪范围。

压测过程中要同时观察本地缓存命中率、失效消息总数、通知连接重连次数和 Redis 的客户端跟踪占用内存。只看接口平均延迟是不够的：如果命中率提升幅度很小，反而新增了大量失效消息，说明缓存对象或者前缀的边界选择得并不合理。

常见问题

Redis Tracking 是不是自动帮我保存本地缓存？

不是。Redis 只负责记录关联关系并发送失效通知，本地的 LRU 淘汰、容量控制、序列化和删除动作都需要客户端自行实现。

收到失效通知后可以不删除，等本地设置的 TTL 到期吗？

不建议这么做。通知就是服务端明确告诉你本地的副本可能已经过期；如果你的业务完全不能接受旧值，收到通知后应该立即删除本地副本再回源拉取新数据。

客户端重连后旧缓存还能直接使用吗？

只有客户端能证明跟踪关系已经完全恢复、且期间没有漏掉任何失效通知的情况下才可以考虑。绝大多数实现里更稳妥的做法是先清空受影响的缓存，再重新从 Redis 读取数据。

OPTIN 和 BCAST 可以一起解决所有缓存问题吗？

不能。OPTIN 用来控制哪些读取请求会进入跟踪范围，BCAST 用来实现按前缀广播失效通知；它们都不能替代权限隔离、容量淘汰和故障恢复的整套设计。