Redis 客户端缓存 OPTIN 与 OPTOUT 怎么选

Redis 客户端缓存的选择可以先看一个判断：如果只有少量明确的读请求允许进入应用本地缓存，优先考虑 OPTIN；如果大多数只读结果都值得先尝试缓存，只需要排除少数动态键，OPTOUT 更省代码。两者都依赖 Redis Tracking 发送失效消息，区别在于“哪些读取默认会被跟踪”。

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

先看默认行为：缓存范围由谁决定

Redis Tracking 会记录客户端读过的键，并在键被修改、过期或因内存策略被淘汰时发送失效通知。客户端收到通知后必须删除本地副本，否则仍可能返回旧值。OPTIN 与 OPTOUT 只改变进入这套跟踪机制的入口。

OPTIN：把缓存资格写在读取前

启用 OPTIN 后，普通的 GET 不会自动进入跟踪集合。应用决定要缓存某个键时，必须紧挨着读取命令发送 CLIENT CACHING YES。这个标记只影响下一条命令；如果下一条是事务，事务内命令会一起被跟踪，脚本中的读取也有相应的整体语义。

# 开启显式加入模式：普通读取默认不进入客户端缓存跟踪
redis-cli CLIENT TRACKING ON OPTIN

# 只有紧随其后的 GET 会被允许进入跟踪集合
redis-cli CLIENT CACHING YES
redis-cli GET user:1001

# 这个读取没有前置标记，默认不会被跟踪
redis-cli GET realtime:counter

这种方式适合把“是否值得缓存”放到业务层判断，例如只缓存商品详情、配置快照或权限元数据，而不缓存持续变化的计数器。代价是连接池或客户端封装必须保证控制命令与目标读取不会被其他请求插入。

OPTOUT：默认纳入，再排除动态键

OPTOUT 适合由统一缓存层接管大部分只读请求的场景。启用后，读取结果默认会被跟踪；对于实时性要求高、命中率低或不希望占用本地内存的键，再用 CLIENT UNTRACKING 排除。排除动作应该和缓存策略一起封装，避免业务代码到处记住例外。

# 开启默认跟踪模式：读取到的键默认具备失效通知资格
redis-cli CLIENT TRACKING ON OPTOUT

# 实时计数器不进入本连接的客户端跟踪集合
redis-cli CLIENT UNTRACKING realtime:counter

# 商品详情仍按默认规则参与跟踪
redis-cli GET product:42

不要把 OPTOUT 理解成“所有数据都应该长期放在本地”。客户端仍需要设置本地内存上限、淘汰策略和最大 TTL；Redis 文档也建议即使服务端键没有 TTL，本地缓存仍设置一个最大存活时间，防止连接或实现缺陷让旧值停留过久。

按三种真实场景做选择

第一种是“少量键值得缓存”：例如一个进程只缓存经过成本评估的配置和详情，选 OPTIN，白名单边界清晰。第二种是“读多写少且大多数对象都值得缓存”：选 OPTOUT，让统一客户端默认接管，再维护一份排除清单。第三种是“键空间很大但只想按前缀接收变化”：可以进一步评估 BCAST 广播模式，它不维护每个客户端已读键的失效表，却会把匹配前缀的变更通知给订阅客户端，消息量和服务端 CPU 成本要单独压测。

别忽略失效连接和并发时序

如果用 RESP3，数据与失效消息可以在同一连接上复用；RESP2 常用数据连接加失效连接的双连接模型，并通过 REDIRECT 把通知转到指定连接。失效连接断开时，最安全的动作不是继续服务旧本地值，而是清空本地缓存，恢复连接后重新读取。

双连接还存在一个容易漏掉的竞态：数据连接发出 GET 后，失效连接可能先收到该键的失效通知，随后数据连接才返回旧结果。可以先把本地条目标成“读取中”，收到失效时删除它；如果旧结果晚到且条目已被删除，就不要把这个结果重新写回缓存。单连接能利用消息顺序降低这类处理复杂度。

# 双连接示意：失效连接的 ID 由 CLIENT ID 返回
redis-cli CLIENT ID

# 数据连接把通知重定向到失效连接；实际 ID 应由连接初始化阶段注入
redis-cli CLIENT TRACKING ON REDIRECT 1234 OPTIN

# 写入连接可按本地缓存策略评估是否使用 NOLOOP，避免自写值立刻收到自身失效
redis-cli CLIENT TRACKING ON NOLOOP OPTIN

上线前的五项检查

1. 列出真正需要本地缓存的键族，先估算命中率和变化频率。
2. 确认 OPTIN 的控制命令与目标读取在同一逻辑连接上，不被连接池交错。
3. 为 OPTOUT 建立可审查的排除清单，优先排除持续变化的计数器和低命中键。
4. 定义客户端内存上限、淘汰策略和最大 TTL；失效连接断开时立即清空本地副本。
5. 灰度观察本地命中率、失效消息数量、重连次数和旧值投诉，再扩大缓存范围。

相关问题

OPTIN 会不会让每次读取都多一次网络往返？

如果控制命令和读取通过同一连接连续发送，协议上确实多了一个命令；应由客户端库做批量发送或封装，而不是让业务层手写散落的命令。

OPTOUT 能不能只排除一个键？

可以使用 CLIENT UNTRACKING key 排除指定键，但要把它和本地缓存策略绑定，否则后续读取可能再次按默认规则进入跟踪。

收到失效消息后只更新本地值可以吗？

更稳妥的默认动作是删除本地副本，下一次读取再回源。只有能证明写入顺序和版本号完整时，才考虑直接更新。

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

当数据变化频繁、访问很分散、客户端内存紧张或业务不能接受短暂旧值时，先使用 Redis 服务端缓存或直接回源，避免为失效通知增加复杂度。