如何解决Redis主从同步中断引发的事务不一致_理解Redis复制不保证强一致

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被清空而被迫走全量同步。

• 全量同步期间主节点仍在写入，新数据不会进入旧RDB快照
• RDB生成到传输完成存在时间窗口，这期间的写操作由增量同步补，但前提是repl-backlog还活着
• 生产环境建议调大repl-backlog-size（如512mb）并延长repl-backlog-ttl（如7200），但不能无限延——内存和磁盘压力会上升

WAIT命令能缓解但不能消除事务不一致

WAIT 2 1000会让主节点阻塞，直到至少2个从节点确认收到并执行了当前命令。但它只对**当前命令**生效，不保证之前或之后的命令顺序一致。

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

真正可控的落地动作只有三类

别寄希望于“自动修复”，主从架构下事务一致性必须靠业务层兜底。

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

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