从节点默认不执行任何过期逻辑，仅重放主节点发来的DEL等命令；必须设maxmemory-policy为noeviction（或7.0+启用replica-ignore-maxmemory yes）防止主动淘汰破坏一致性。
从节点默认就是只读且不主动过期 Key，但容易被 slave-read-only 和 maxmemory-policy 误导
Redis 从节点（replica）在 2.6+ 版本中默认开启 slave-read-only yes，这仅控制客户端能否写入，并不决定 Key 过期行为。真正影响“是否删 Key”的是过期逻辑本身：从节点**完全不执行被动过期（lazy expiration）和主动过期（active expiration）**，它只响应主节点发来的 DEL、EXPIRE 等写命令的复制流。
常见误操作是给从节点配了 maxmemory-policy volatile-lru 或类似策略，以为只是内存管理——其实只要配置了非 noeviction 策略，从节点在内存超限时会**自己触发淘汰并发送 DEL 给自身**，这就破坏了一致性。
- 必须将从节点的
maxmemory-policy设为noeviction - 确保
maxmemory不设为 0（即不限制），或设为一个安全值但搭配noeviction - 检查
redis.conf中是否显式覆盖了slave-read-only，虽然它不影响过期，但改错可能暴露运维漏洞
主从复制流里没有“过期时间到”事件，只有 DEL / EXPIRE / PEXPIRE 命令
Redis 的过期机制是单机行为：主节点在 key 过期时，要么在访问时懒删除（lazy），要么在后台周期性抽样删（active）。这些动作最终都转化为一条 DEL 命令（或带过期的 SET）进入复制缓冲区，从节点只负责重放。
所以从节点上看到一个 key “还在”，不是它没同步，而是主还没删；看到“突然消失”，说明主已触发删除并成功复制。你无法让从节点“提前感知过期”，也不能让它“延迟删除”——它根本没有过期时钟。
- 不要在从节点调用
ttl或expiretime期待和主一致：如果主刚删完，从可能还缓存着旧 TTL（直到收到 DEL） -
EXPIRE命令本身会被复制，但如果主在过期前就执行了EXPIRE key 0，从也会立刻删，这不是“主动过期”，是命令重放 - 使用
WAIT命令不能保证过期同步，它只等 ACK，不等 DEL 到达
启用 replica-ignore-maxmemory yes（Redis 7.0+）是最省心的兜底方案
Redis 7.0 引入了这个开关，明确告诉从节点：“别管 maxmemory 和淘汰策略，哪怕 OOM 也别删 key”。它本质上是强制把从节点的淘汰逻辑置空，比手动设 noeviction 更彻底——连内存超限日志都不会触发淘汰流程。
- 仅适用于 Redis ≥ 7.0，低版本只能靠
noeviction+ 合理预估内存 - 仍需配合
slave-read-only yes，防止人为DEL - 该配置不影响主节点行为，也不影响 AOF/RDB 快照内容
验证是否真没删：用 redis-cli --rdb 或 debug object 看底层状态
光看 exists key 或 get key 不够——key 可能存在但已逻辑过期（比如 ttl 返回 -2）。真正确认从节点没主动删，得查它的实际存储状态：
- 连接从节点执行
debug object key：若返回value at:0x...，说明 key 还在内存里；若报(error) ERR no such key，说明已被删（大概率是主同步来的 DEL） - 用
redis-cli --rdb /dev/stdout | strings | grep your_key抓 RDB 快照（需停写或 bgsave），可确认某时刻 key 是否被持久化 —— 从节点 RDB 不会包含已过期未删的 key，但也不会凭空删掉主还没删的 key - 监控
stat_expired_keys指标：从节点该值始终为 0，主节点才会计数
最麻烦的点其实是“主节点过期逻辑本身不可控”：如果主用了 volatile-ttl 且 key 大量集中过期，可能造成复制延迟突增，导致从节点看起来“滞后很久才删”。这不是从节点的问题，但你会第一个在从上观察到现象。
