Redis WAIT 怎么确认副本已追上：超时返回、复制延迟与写入确认边界

订单写入 Redis 主节点后，业务有时需要立刻把结果交给另一个读取链路。如果只看到主节点返回 OK，并不能说明副本已经收到这次写入。Redis 的 WAIT 可以让当前连接等待指定数量的副本确认，并返回实际确认数；超时也会返回，不能把“命令返回”直接当成“达到目标”。

先用一个返回值判断副本是否达标

准备一个有主节点和至少一个副本的测试环境。应用连接保持不变，先写入带有本次请求标识的键，再执行 WAIT 1 800：

SET order:confirm:20260821 paid EX 60
WAIT 1 800

如果结果是整数 1，表示这条连接此前的写命令至少被一个副本确认。若返回 0，只能说明在 800 毫秒内没有副本确认，不代表主节点的 SET 失败。业务是否继续，应由调用方明确决定。

超时不是异常响应：先比较目标值和实际值

WAIT 的第二个参数单位是毫秒，达到超时时间后命令会返回当前已确认的副本数量。例如要求两个副本，但拓扑里只有一个可用副本：

SET stock:sku-1001 8
WAIT 2 1000
// 可能返回：(integer) 1

此时不能因为客户端没有收到 Redis 错误，就把请求标记成“双副本确认成功”。可靠判断只有一个：把返回值与要求的 numreplicas 比较，ack >= required 才算达到门槛。

为什么同一条连接很重要

Redis 会记住每个客户端连接产生的复制流偏移。WAIT 检查的是当前客户端在它之前发出的写入，因此下面这种顺序才有明确语义：

连接 A：SET order:confirm:20260821 paid
连接 A：WAIT 1 800

连接 B：WAIT 1 800  // 不能用来确认连接 A 的 SET

在连接池里，如果业务代码先从连接 A 执行写入、归还连接，再从连接 B 调用 WAIT，确认对象就不再清楚。实现上应使用支持同一连接上下文的客户端封装，或者让“写入加复制确认”成为一个不可拆开的操作。

事务也要单独测试。Redis 文档说明，WAIT 放进 MULTI 等不允许阻塞的上下文时不会按普通阻塞命令等待，而是尽快返回已经确认的数量。

用 INFO replication 解释等待变慢的原因

当 WAIT 经常返回较小的数量，先看复制拓扑和延迟，再调大超时。管理员连接可以读取：

INFO replication

重点关注 role、connected_slaves（新版本也可能显示为 replica 相关字段）、副本连接状态和复制偏移。复制链路拥塞、网络抖动、副本正在加载 RDB，都会让等待时间变长。不要把 WAIT 1 0 当成万能修复，它可能让请求在副本长期不可用时一直占住连接。

生产配置通常需要同时设定请求总超时和 WAIT 超时，并把实际确认数、等待耗时、主从拓扑状态写进指标。这样才能区分“主节点写成功但副本未追上”和“主节点本身写入失败”。

复制确认不等于强一致和持久化

WAIT 能把异步复制变成一次客户端可观察的等待，但它不会让 Redis 自动变成强一致存储。副本确认只说明写命令已经被指定数量的副本接收；故障切换、网络分区、持久化策略和应用读路径仍会影响最终结果。

如果需求是“支付状态必须有明确的持久化与恢复保证”，还要把 AOF/RDB 策略、故障转移方案、幂等键和业务数据库事务一起评估。WAIT 更适合做复制安全门槛，而不是替代完整的可靠性设计。

常见问题

WAIT 返回 0 是否表示 SET 失败？

不是。它表示在给定等待时间内没有副本确认当前连接此前的写入，主节点上的 SET 可能已经成功。

WAIT 的 timeout 单位是什么？

单位是毫秒。设置为 0 表示一直等待，不建议在没有外层请求超时的情况下使用。

WAIT 能保证读请求一定读到最新值吗？

不能。它只提供复制确认数量，读请求还要确认访问的是哪个节点以及读路由是否允许副本延迟。

连接池会影响 WAIT 吗？

会。写入和 WAIT 应保持同一连接上下文，否则后一个命令无法可靠对应前一个连接产生的写入。

把确认门槛写成业务判断

落地时不要只记录 Redis 命令是否返回，而要记录 required、ack、等待耗时和拓扑状态。只有 ack >= required 才标记为达到复制确认门槛；未达到时保留主节点写入结果，再按业务选择重试、降级或交给后续补偿流程。