redis主节点异步淘汰不走复制流，从节点收不到del命令，导致数据不一致；需关闭lazyfree-lazy-eviction、lazyfree-lazy-expire及lazyfree-lazy-server-del，并保障从节点处理能力与网络稳定。
主节点异步淘汰不走复制流，从节点根本收不到DEL
Redis默认启用lazyfree-lazy-eviction yes和lazyfree-lazy-expire yes时，内存淘汰（如maxmemory-policy volatile-lru触发）和过期键清理会交给后台线程执行。这些后台删除**不会生成DEL命令写入复制缓冲区**，也不会进入AOF重写流程。结果就是：主节点内存里key没了，但从节点完全不知道——它只认客户端显式发来的DEL、EXPIRE、SET等命令。
常见错误现象包括：
- 业务层调用
DEL order:123后立刻读从库，仍返回旧值 -
INFO replication显示master_repl_offset远大于slave_repl_offset，但redis-cli --bigkeys在从库还能扫出大量“幽灵key” - 主节点
INFO memory中lazyfree_pending_objects长期非零，而从节点对应key始终存在
配置项没关全，后台淘汰照样偷偷删
很多人只改了lazyfree-lazy-eviction no，却漏掉lazyfree-lazy-expire no。只要后者仍是yes，过期键仍由后台线程清理，同样不进复制流。更隐蔽的是，某些Redis版本（如6.2+）还新增了lazyfree-lazy-server-del，用于FLUSHDB等命令的异步清理，也得一并设为no。
验证是否生效的关键动作：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
CONFIG SET maxmemory 1mb人为触发淘汰，再快速SET一批key直到OOM - 立刻在从节点
GET刚被主节点淘汰的key，应返回(nil)而非旧值 - 检查
INFO memory输出，确认lazyfree_pending_objects为0且不再上涨
即使淘汰同步了，从节点回写慢也会造成延迟堆积
就算所有删除都走主线程+复制流，从节点自身处理能力不足仍会导致命令积压。典型瓶颈包括：
- 从节点CPU弱或磁盘I/O慢，
REPLCONF ACK反馈滞后，主节点复制缓冲区持续增长 -
repl-backlog-size太小，网络抖动断连后无法部分重同步，被迫全量重同步（SYNC） - 从节点正在执行
BGSAVE或AOF rewrite，阻塞命令执行队列
这时INFO replication会显示slave_repl_offset明显落后，且repl_backlog_active为1但repl_backlog_histlen接近repl_backlog_size上限。
读写分离下不能只靠配置保底
配置修正只能解决“淘汰不传播”这个环节，但网络传输延迟、从节点命令排队、甚至WAIT命令只保证传播不保证执行，都意味着强一致场景必须应用层兜底：
- 对订单、库存等关键key，读操作直接打主节点，绕过从库
- 若必须读从库，先
DEL key再紧跟WAIT 1 500，但要清楚WAIT返回成功≠从节点已执行完该DEL - 避免依赖TTL自动过期，改用业务层主动
EXPIREAT+定时清理，确保删除动作可控可追踪
最易被忽略的一点：即使所有配置正确、网络稳定，从节点上一个慢查询（比如HGETALL大Hash）仍在执行时，新到达的DEL命令会被堵在队列里——Redis单线程模型决定了这是硬约束，不是靠调参能绕过的。
