Redis 客户端缓存怎么用 TRACKING 避免脏读

Redis 客户端缓存要避免脏读，关键不是把本地缓存的 TTL 调得更短，而是让 Redis 在被跟踪的 key 发生变化时发出失效消息，客户端收到 INVALIDATE 后立即删除本地副本。这个机制叫 server-assisted client-side caching，核心命令是 CLIENT TRACKING。

官方入口：https://redis.io/

先看清 TRACKING 能保证什么

Redis 会记录启用跟踪的连接读过哪些 key。之后任意客户端修改该 key，或者 key 因过期、淘汰而失效，Redis 会向可能持有它的客户端发送失效消息。这里的“避免脏读”是客户端不再继续提供已经收到失效通知的值，不是 Redis 替应用完成事务隔离。

客户端必须把普通请求连接和能接收 RESP3 push 消息的连接关系设计清楚。若连接池把失效消息交给了错误的请求协程，或者收到通知后只记录日志、不删除本地条目，TRACKING 仍然可能表现为读到旧值。

默认跟踪、OPTIN 和 BCAST 怎么选

最小协议示意如下。它是静态命令示例，不代表某次线上执行结果：

# 使用支持 RESP3 push 消息的连接开启服务端辅助缓存
redis-cli -3
CLIENT TRACKING ON

# 读取后，Redis 记录该连接可能缓存了 user:42
GET user:42

# 另一个连接修改同一个 key，原连接会收到 INVALIDATE user:42
SET user:42 "new-value"

# 客户端处理失效消息时必须删除本地副本，而不是继续返回旧值
# 删除后下一次 GET 再回到 Redis 读取

处理 INVALIDATE 才是防脏读的关键动作

实现时可以把本地缓存看成一个带失效入口的映射：读命中直接返回；读 Redis 后写入映射；收到 INVALIDATE key 就删除对应键。删除动作要先于下一次对外读返回，不能把通知积压在普通业务队列里再慢慢处理。

如果客户端要缓存自己刚写入的值，可以研究 NOLOOP。它能抑制写入连接收到自己的回环失效消息，但默认跟踪模式下 Redis 仍会移除该连接对这个 key 的跟踪；客户端后续重新读取后，才会再次进入跟踪集合。不要把 NOLOOP 理解成“写入后永远不会失效”。

广播模式则按前缀发送通知，例如 user:。它省去了服务端为每个客户端记录具体 key 的关系，但会把前缀命中的变化通知给订阅者。用户缓存很少时，默认模式通常更省心；命名空间清晰且需要按组失效时，BCAST 才更有价值。

连接池、数据库编号和容量是三个常见坑

第一，跟踪状态属于连接，不属于抽象的业务缓存对象。使用连接池时，要确认通知监听和本地缓存归属是一致的，不能让连接 A 读出的 key 由连接 B 的缓存表代管。

第二，Redis 的跟踪表不是无限增长的。官方文档说明，跟踪表达到上限时可能淘汰较早的关系，并向客户端发送一次失效通知；这会牺牲部分缓存命中率，但客户端应把它当作安全的删除信号。第三，跟踪关系不按数据库编号拆开，同名 key 在不同 DB 之间也可能触发通知，所以不要依赖 DB 编号隔离本地缓存命名。

上线前至少记录三项：本地缓存命中率、INVALIDATE 消息数量、失效后的回源比例。若失效消息远多于命中收益，说明缓存范围过宽；若通知到达后仍有旧值返回，优先排查连接归属和删除时序，而不是继续缩短 TTL。

相关问题

TRACKING 能保证跨服务事务一致吗？

不能。它解决的是已读 key 的客户端副本失效通知；跨表事务、读写隔离和业务版本判断仍要由应用或数据库方案负责。

收到 INVALIDATE 后能不能只更新本地值？

可以在业务允许时主动回源更新，但安全默认是先删除旧值，再由下一次读取获取新值，避免通知处理期间继续暴露旧副本。

客户端只支持 RESP2 还能直接用吗？

要看客户端是否提供专门的 RESP3 转发连接或库级封装。若不能可靠接收 push 失效消息，就不要把它当作已经启用的一致性机制。