从节点不执行淘汰逻辑，因只读且无写入触发内存增长；maxmemory仅限后台任务，淘汰策略完全不生效；淘汰通过DEL/EXPIRE命令经复制流同步。
主节点的内存淘汰操作本身不会“同步”给从节点——它根本不需要同步，因为淘汰逻辑在从节点上不执行。
为什么 maxmemory 和淘汰策略（如 volatile-lru）在从节点上被忽略？
Redis 从节点默认开启 slave-read-only yes，且其内存管理行为与主节点有本质区别：
- 从节点只响应读请求，不接受写命令，因此不会触发写入导致的内存增长和淘汰判定；
-
maxmemory配置在从节点上仅用于限制自身后台任务（如 RDB 加载、AOF 重写）的内存使用，不影响复制数据的存储； - 淘汰策略（
maxmemory-policy）在从节点上完全不生效：即使你配了allkeys-lfu，从节点也不会主动驱逐 key； - 所有数据变更（包括因主节点淘汰导致的 key 删除）都通过复制流（replication stream）以命令形式传播，例如
DEL key或EXPIRE key，从节点只是忠实执行这些命令。
DEL 和 EXPIRE 命令才是真正的“淘汰同步机制”
主节点发生淘汰时，并不是直接通知从节点“删掉这个 key”，而是把淘汰动作翻译成标准 Redis 命令，再走常规复制流程：
- 若淘汰的是设置了过期时间的 key，主节点会先触发
EXPIRE或直接DEL（取决于是否已过期），该命令进入复制积压缓冲区，随后发给从节点； - 若淘汰的是无过期时间的 key（如
allkeys-random策略），主节点执行DEL key，该命令同样被复制； - 从节点收到后，像处理任何客户端发来的
DEL一样执行，结果与主节点一致； - 注意：
MEMORY PURGE或MEMORY MALLOC-STATS这类运维命令不参与复制，也不影响数据一致性。
容易踩的坑：误以为从节点也会“自主淘汰”
常见错误配置或误判场景：
- 在从节点上手动修改
maxmemory并设为较小值，误以为能“提前释放内存”——实际只会让 AOF rewrite 或 RDB save 失败，甚至触发 OOM killer； - 监控发现从节点
used_memory比主节点高，就怀疑“淘汰没同步”——其实是因为从节点未执行过写命令，mem_fragmentation_ratio更高，或主节点刚淘汰完、命令尚未到达从节点（存在短暂延迟）； - 用
INFO memory查看从节点的maxmemory_human和maxmemory_policy，误把配置值当成运行时行为——它们只是配置项，不驱动淘汰逻辑； - 哨兵故障转移后，新主节点（原从节点）启用
maxmemory，但此时它已脱离只读状态，必须重新评估并配置淘汰策略，否则可能 OOM。
真正需要关注的，是主节点淘汰触发的命令能否稳定进入复制流——这依赖于 repl-backlog-size 是否足够大、网络是否稳定、从节点是否长时间断连。一旦命令丢失，就会出现主从 key 数量或 TTL 不一致，而这种不一致无法靠“自动重同步”修复，只能靠全量重同步或人工干预。
