Redis主从同步中断导致事务不一致的解决方法

Redis主从复制一旦中断，事务级别的数据不一致并不会因为重新连接而自动修复。这中间存在一个容易被忽视的盲区：中断期间主节点持续写入，一旦这些写操作超出复制积压缓冲区（repl-backlog）的保留范围，从节点重新连接后只能触发全量同步，而中断期间的事务状态已彻底丢失，再也无法追溯。

为什么INFO replication显示的connected_slaves=1却仍存在数据不一致？

connected_slaves这个指标，实际上只代表TCP链路仍然存活，与命令是否成功执行到从节点完全是两回事。真正能反映复制进度的指标，是master_repl_offset减去slave_repl_offset的差值。只要这个差值不为0，就说明有命令正在传输中或者已经丢失。

• 差值为0：大概率一致（但还需排除网络丢包未触发重传的特殊情况）
• 差值稳定增长：从节点的复制线程卡住，或者网络持续丢包
• 差值突然飙升后归零：刚经历了一轮全量同步，但中断期间的事务早已丢失

repl-backlog-ttl超时：触发全量同步的隐形开关

主节点默认保留复制积压缓冲区最多3600秒（repl-backlog-ttl 3600）。一旦从节点断连超过这个时长，即使只差几个字节，也会因为repl-backlog被清空而被迫执行全量同步。这里的代价十分隐蔽：

• 全量同步期间主节点仍在持续写入，新数据不会进入老的RDB快照
• 从RDB生成到传输完成存在时间窗口，这期间的写操作需要依靠增量同步来补充，前提是repl-backlog仍然有效
• 生产环境建议调大repl-backlog-size（例如512MB）并延长repl-backlog-ttl（例如7200秒），但也不能无限制放大——内存和磁盘压力会随之上升

WAIT命令能缓解事务不一致，但无法彻底消除

WAIT 2 1000可以让主节点阻塞，直到至少2个从节点确认收到并执行了当前命令。但请注意，它仅对当前这一条命令生效，无法保证之前或之后的命令在顺序上保持一致。几个典型的短板如下：

• 它无法防止网络分区导致从节点永久失联
• 如果从节点在WAIT超时前崩溃，主节点仍然会返回成功，客户端误以为已经同步
• 高并发下频繁使用WAIT会显著拖慢写吞吐，这与Redis异步设计的初衷背道而驰

真正可控的落地措施只有三类

不要指望所谓的“自动修复”，在主从架构下，事务一致性必须由业务层来兜底。

• 读敏感场景强制读主：例如下单后查订单、支付后查余额，直接从主节点读取，绕过从节点
• 写后延迟+校验读：写入主节点后sleep 50ms，再从从节点读取；如果读不到或值不符，立即fallback到主节点读取
• 关键事务用Lua脚本封装：将读-判-写逻辑压入一个原子操作，避免主从之间的状态分裂

最容易忽略的一点：全量同步并不是“恢复一致”，而是“放弃一致”。中断期间发生的事务，在从节点视角里从来就没有存在过。