Redis主从同步中断后无法自动修复事务不一致，因repl-backlog超时清空导致全量同步，丢失中断期事务；connected_slaves=1仅表示TCP连接正常，真正一致性需看master_repl_offset与slave_repl_offset差值是否为0。
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被清空而被迫走全量同步。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 全量同步期间主节点仍在写入，新数据不会进入旧RDB快照
- RDB生成到传输完成存在时间窗口，这期间的写操作由增量同步补，但前提是
repl-backlog还活着 - 生产环境建议调大
repl-backlog-size（如512mb）并延长repl-backlog-ttl（如7200），但不能无限延——内存和磁盘压力会上升
WAIT命令能缓解但不能消除事务不一致
WAIT 2 1000会让主节点阻塞，直到至少2个从节点确认收到并执行了当前命令。但它只对**当前命令**生效，不保证之前或之后的命令顺序一致。
- 它无法防止网络分区导致的从节点永久失联
- 如果从节点在
WAIT超时前崩溃，主节点仍会返回成功，客户端误以为已同步 - 高并发下频繁用
WAIT会显著拖慢写吞吐，违背Redis异步设计初衷
真正可控的落地动作只有三类
别寄希望于“自动修复”，主从架构下事务一致性必须靠业务层兜底。
- 读敏感场景强制读主：比如下单后查订单、支付后查余额，绕过从节点
- 写后延迟+校验读：写主后sleep 50ms，再从从节点读；若读不到或值不符，立即fallback主读
- 关键事务用Lua脚本封装：把读-判-写逻辑压进一个原子操作，避免主从间状态分裂
最易被忽略的一点：全量同步不是“恢复一致”，而是“放弃不一致”。中断期间发生的事务，在从节点视角里从未存在过。
