Redis6.0客户端缓存淘汰机制解析

Redis 6.0 的客户端缓存（tracking）机制虽能高效感知显式命令（如DEL、SET、EXPIRE等）引发的key变更并推送invalidation消息，却完全无法感知由内存淘汰策略（如LRU/LFU）导致的key被动驱逐——因为淘汰是后台异步行为，不经过命令执行路径，也不触发任何通知机制；这造成了一致性盲区：客户端可能长期持有已被静默淘汰却未收到通知的“脏”缓存。因此，仅依赖tracking远不够，必须通过本地缓存提前过期、GET后校验、空结果回源刷新等主动兜底策略来弥补这一根本性缺陷，否则业务将面临难以排查的缓存不一致风险。

能感知，但仅限于明确被修改或删除的 key，不包括因内存淘汰（如 maxmemory 策略触发的 LRU/LFU 驱逐）而被动下线的 key。

为什么内存淘汰不会触发 invalidation 消息

Redis 的客户端缓存 tracking 机制本质是「写时通知」：只有当某个 key 被显式执行了 DEL、SET、INCR、HSET 等变更命令时，服务端才会检查该 key 是否被某些 client tracking 记录，并推送 PUSH 类型的 invalidation 消息。

而内存淘汰（例如 volatile-lru 或 allkeys-lfu）是后台异步执行的驱逐行为，不走命令执行路径，也不产生 AOF / repl log，更不会触发 key space notification。tracking 模块根本不知道这个 key 是“被删了”，它只是“不见了”。

• 服务端不会为 evicted 事件生成 invalidation 消息
• CLIENT TRACKING ON 不监听 evict 事件，只监听命令执行上下文中的 key 变更
• 即使开启了 notify-keyspace-events Ex，也仅影响 Pub/Sub，不影响 tracking 推送

哪些操作会真正触发 invalidation 消息

只有明确改变 key 状态的命令才会上报。注意：不是所有读写命令都算「变更」——只影响 value 或元数据的才算。

• DEL、UNLINK：key 被删除 → 触发
• SET、GETSET、SETEX、PSETEX：value 被覆盖 → 触发
• INCR/DECR、HSET/HDEL、SADD/SREM 等结构变更命令 → 触发
• EXPIRE/PEXPIRE、EXPIREAT：key 过期时间被修改 → 触发（注意：过期本身不触发，改过期时间才触发）
• RENAME、RENAMENX：源 key 被移除 → 触发源 key 的 invalidation

反例：GET、EXISTS、TTL、OBJECT 等纯读命令，无论是否命中，都不会触发任何推送。

如何应对内存淘汰导致的本地缓存脏数据

这是客户端缓存最常被忽略的一致性盲区。不能依赖 tracking 自动兜底，必须主动设计 fallback 和兜底策略：

• 本地缓存需设置比 Redis TTL 更短的过期时间（例如 Redis 设 60s，本地设 45s），用时间窗口缓冲淘汰风险
• 对关键 key，在 GET 后加一层 EXISTS 或 TTL 校验（代价小，但能捕获已淘汰 key）
• 启用 CLIENT TRACKING ON REDIRECT + 单独连接接收 push，并在收到 invalidation 后立即清空本地对应 key —— 但这仍不覆盖淘汰场景
• 业务层对「空结果」保持警惕：若本地有缓存但 GET 返回 nil，应视为可能被淘汰，触发回源 + 强制刷新本地缓存

RESP3 push 消息本身无法区分淘汰还是主动删除

客户端收到的 invalidation 消息格式统一为：PUSH + invalidate + [key1 key2 ...]。它不携带原因字段，也不包含事件类型（如 evicted vs deleted）。你只能知道 “这个 key 不再可信”，但无法判断它是被 DEL 还是被 LRU 给踢出去的。

这意味着：哪怕你完整实现了 RESP3 push 解析和本地缓存清理逻辑，依然要为「没收到消息却已失效」的情况留余地 —— 淘汰就是静默发生的，没有 hook，没有回调，也没有日志可查。

以上就是《Redis6.0客户端缓存淘汰机制解析》的详细内容，更多关于的资料请关注golang学习网公众号！