Redis 主从切换为什么会丢数据？WAIT 能解决吗？

Redis 主节点返回写入成功，默认只说明它已经执行了该命令，不意味着所有副本已经接收、应用并持久化。若主节点随后故障，故障转移选中的副本没有这条修改，客户端收到成功响应的数据仍可能丢失。

三个保证不要混淆#

例如 A 写入订单状态并返回成功，在 B 应用该修改前 A 宕机，B 被提升为主节点，就会缺少这次更新。即使 A 配置 AOF 每次刷盘，也不能自动让 B拥有 A 磁盘上的日志。持久化提高本节点恢复能力，复制提高其他节点接管能力，二者作用不同。

在同一客户端连接上完成写入后，WAIT 1 1000 请求最多等待 1000 毫秒，直到至少一个副本确认达到该连接之前写入对应的复制位置。返回值是实际确认的副本数量，可能低于目标；应用不能忽略返回值就宣称写入可靠。

WAIT 提高数据存在于多个节点的概率，但没有把 Redis 改成强一致性共识系统。确认不等同于副本磁盘刷盘，故障转移也不承诺一定选中已经确认的副本。Redis 7.2 引入的 WAITAOF 进一步涉及 AOF 同步确认，使用前仍需检查版本、持久化配置和其具体语义。

不保证。它限制主节点在健康副本数量与延迟条件不足时接受写入，属于降低风险的准入条件，不是逐条写入的同步提交协议。

不能。SET 可能已在主节点执行，只是复制确认没有达到要求。超时后的重试要考虑幂等性和结果不确定性。

仍不绝对安全。还存在租约过期、客户端暂停和资源端旧请求继续执行的问题。关键业务需要数据库约束或 fencing token 等资源端校验。

支付结果、唯一订单账本等不能容忍丢失的核心事实，应采用符合业务可靠性要求的持久化存储；Redis 可以加速访问或协调，但业务正确性要有可恢复的依据。