Redis从节点只读过期配置详解

Redis从节点默认不执行任何过期逻辑，仅被动重放主节点发送的DEL、EXPIRE等命令，因此其Key生命周期完全由主节点决定；但若错误配置非noeviction的maxmemory-policy（如volatile-lru），从节点会在内存超限时主动淘汰Key并触发本地DEL，严重破坏主从数据一致性——这是运维中最隐蔽也最危险的陷阱；正确做法是将从节点maxmemory-policy严格设为noeviction（Redis 7.0+更推荐启用replica-ignore-maxmemory yes彻底禁用淘汰），同时保持slave-read-only yes，并通过debug object或RDB快照验证Key真实存在状态，而非依赖ttl或exists判断；本质上，Redis的过期机制是单机行为，复制流中没有“时间到”事件，只有命令流，理解这一点才能避免所有关于从节点“提前/延迟过期”的误解。

从节点默认就是只读且不主动过期 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 大量集中过期，可能造成复制延迟突增，导致从节点看起来“滞后很久才删”。这不是从节点的问题，但你会第一个在从上观察到现象。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。