从节点不删过期键是设计使然，不是故障：所有过期逻辑仅在主节点执行，从节点只重放主节点发出的del命令，自身绝不调用dbdelete()物理删除。
从节点不删过期键是设计使然，不是故障
Redis 从节点（replica）压根不会主动判断或删除任何过期键——这不是 bug，而是明确的设计约定。所有过期逻辑只在主节点（master）执行：主节点发现 key 过期后，会发出 DEL key 命令，从节点只是原样重放这条命令。这意味着，只要主节点还没删、或者 DEL 没同步到，从节点上那个 key 就“物理存在”，哪怕 TTL key 返回 -1 或负数，GET key 仍可能返回旧值。
为什么从节点的 GET 还能读到已过期 key
常见误判场景如下：
- 主节点因
hz太低或负载高，迟迟未触发定期删除，导致过期 key 积压；从节点没收到DEL，自然还存着 - 主从断连后重连，触发全量同步（RDB 加载），而 RDB 文件里保留了快照时刻所有带
expires字典的 key —— 其中很多在主上早已被删，但从加载后就“复活”成幻影过期键 - 客户端直连从节点读取（如开启
replica-serve-stale-data yes），且未做二次校验，把从节点返回的旧值当真
注意：expireIfNeeded() 在从节点上仅用于返回 nil（比如 GET 时发现已过期），但**绝不会调用 dbDelete() 物理删除**——这是和主节点最本质的区别。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正有效的应对方式不是“让从节点删”，而是切断误用路径
你无法也不该让从节点承担过期清理职责。可行动作集中在规避与兜底：
- 读写分离场景下，对一致性敏感的业务必须走主节点读，或加一层逻辑：先
PTTL key判断剩余 TTL，若为负值则跳过缓存直接查源 - 监控
redis-cli -p 6379 info replication | grep "master_repl_offset"和从节点slave_repl_offset差值，差值持续增大说明复制延迟严重，需排查网络或主节点写入压力 - 若确认从节点残留大量幻影过期键（如全量同步后），可对对应 DB 执行
SCAN+PTTL脚本批量识别并DEL，但注意：集群模式下SCAN不跨 slot，需按 slot 分片处理 - 禁止在生产环境长期开启
replica-serve-stale-data yes；设为no后，从节点在断连或同步滞后时直接拒绝读请求，反而暴露问题更早
最容易被忽略的点：被动删除根本没机会触发
很多人盯着 hz 和 active-expire-effort 猛调，却忘了最关键的约束：从节点上的过期键，除非被 GET/EXISTS 等命令访问，否则惰性检查都不会跑，更别说触发 DEL。而如果业务压根不碰那些 key（比如 token 类 key 只写不读），它们就会一直躺在从节点内存里，直到下一次全量同步或手动 FLUSHDB。这种“静默残留”不会报错，但会在数据迁移、扩缩容或故障切换时突然浮现——别等出事才查 INFO keyspace 里 expires= 的数量。
