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脚本封装：将读-判-写逻辑压入一个原子操作，避免主从之间的状态分裂
最容易忽略的一点：全量同步并不是“恢复一致”，而是“放弃一致”。中断期间发生的事务，在从节点视角里从来就没有存在过。
