Redis主从同步中DEL命令不被复制导致从库脏读
Redis主从同步中DEL命令不被复制导致从库脏读
在Redis的默认配置下，有个细节值得警惕：主节点执行DEL命令后，如果这次删除是由内存淘汰机制（比如maxmemory策略下的volatile-lru）触发的，那么被删除的键可能走的是后台线程的异步删除路径。问题来了，这种后台删除操作，既不会写入AOF重写缓冲区，也不会进入复制缓冲区，自然也就无法同步给从节点。
结果就是，主库的数据已经没了，从库里却还留着旧值。一旦客户端从从库读取，拿到手的就是过期的“脏数据”。
这并非一个Bug，而是Redis在性能与一致性之间做出的权衡：异步淘汰能避免阻塞主线程，提升响应速度，代价则是牺牲了主从之间删除操作的强一致性。
- 只有客户端显式发起的
DEL、EXPIRE、SET等命令，才会被记录并传播到复制流中；后台淘汰机制悄悄执行的删除，则完全不会。 - 如果开启了
lazyfree-lazy-eviction yes（默认关闭），这个问题会被放大，因为所有淘汰任务都交给了后台线程处理。 - 当然，选择
noeviction策略可以彻底绕过这个问题，但这要求你对内存使用有极其严格的把控，否则写入操作会直接失败。
如何让主节点的淘汰动作也同步到从节点
核心思路其实很明确：堵住异步淘汰的“后门”，强制所有删除操作都走主线程这条“正路”，从而确保它们能进入复制流程。这需要关注两个关键配置：
- 确保
lazyfree-lazy-eviction设置为no（这是默认值，但务必检查是否被其他配置覆盖）。 - 确保
lazyfree-lazy-expire也设置为no，防止过期键的异步删除同样造成不同步。 - 同时，当
maxmemory-policy不是noeviction时，要保证淘汰行为由主线程触发，而非依赖后台线程。
如何验证配置生效了呢？可以在主节点执行INFO memory命令，观察lazyfree_pending_objects指标是否长期为0。更直接的测试方法是人为触发内存淘汰（比如临时将maxmemory设得很小，然后大量写入数据），接着观察从节点上对应的key是否也同步消失了。
读写分离场景下避免脏读的兜底方案
话说回来，即便配置正确，网络延迟、复制缓冲区滞后等因素，仍可能导致主从之间出现短暂的数据不一致。生产环境不能把宝全押在配置上，必须在应用层设计兜底方案：
- 对于那些对强一致性要求极高的key（例如订单状态、库存数量），读操作应当直接请求主节点，绕过从库。
- 如果业务架构上必须读从库，可以考虑使用
WAIT 1 1000命令。它能确保当前的写操作已经传播到至少1个从节点（注意，这需要repl-diskless-sync配置为no，且网络环境稳定）。 - 尽量避免单纯依赖TTL自动过期，可以改用业务层主动执行
DEL并配合同步等待。例如：DEL order:123; WAIT 1 500。
需要警惕的是，WAIT命令只保证写命令传播到了从节点，并不保证从节点已经执行完毕。如果从节点当时正卡在慢查询或者BGSA VE等操作上，命令仍会在其缓冲区中延迟执行。
为什么不用Redis 7的replica-serve-stale-data no？
这个配置项常被误解为“禁止读取脏数据”的银弹。实际上，它的真实作用是：当从节点与主节点连接断开，或者复制偏移量落后太多时，直接拒绝客户端的读请求。它并不能解决在主从连接正常、但因淘汰不同步而导致的脏读问题。
更重要的是，将其设为no意味着，一旦主从同步出现延迟或中断，从节点会直接向客户端返回错误。对于读多写少的服务而言，这种可用性风险带来的影响，可能远比读到短暂脏数据要大——尤其是在网络抖动较为常见的云环境里。
说到底，我们要防范的核心风险，往往不是“从库不可用”（这很容易监控和告警），而是“从库返回了错误的数据”。后者静默发生，排查起来也困难得多。
