Redis WAIT 怎样确认副本复制进度

Redis 的复制默认是异步的。如果一条关键写入需要等待若干副本确认，可以在同一条客户端连接中先发送写命令，再发送 WAIT numreplicas timeout。它返回实际确认了这批写入的副本数量，返回值达到目标才算本次复制确认成功；超时只代表等待结束，不代表写入失败，也不代表强一致。

官方文档：https://redis.io/docs/latest/commands/wait/

把 WAIT 当成“复制确认数检查”，不要当成“事务提交”或“数据永久保存”按钮。生产代码必须比较返回值，并为未达标时的业务处理留出降级路径。

WAIT 只确认副本数，不等于强一致

WAIT 的语法是 WAIT numreplicas timeout。第一个参数表示至少等待多少个副本确认，第二个参数单位是毫秒，设置为 0 表示一直等待。Redis 官方文档说明，它针对的是当前连接此前发送的写命令；命令达到目标后返回，或者在超时后返回已经确认的数量。

这层语义很重要：返回 2 表示至少两个副本已经确认收到当前连接对应的写入，不表示这些副本已经完成磁盘持久化，也不保证故障转移时一定不会丢失数据。Redis 复制文档也明确指出，WAIT 可以降低特定故障下的丢写概率，但不会把异步复制集群变成 CP 系统。

先把写入和 WAIT 放在同一条连接上

WAIT 的确认范围跟客户端连接有关。不要让写入走连接 A、WAIT 走连接 B，再用 B 的返回值推断 A 的写入；连接池场景尤其容易把这个边界藏起来。下面用 go-redis 展示一个保持同一客户端对象的最小写法，示例只表达调用关系，具体超时应按业务延迟预算调整。

package main

import (
    "context"
    "fmt"
    "time"

    "github.com/redis/go-redis/v9"
)

func saveWithReplicaAck(ctx context.Context, client *redis.Client) error {
    // 先写主节点，再在同一客户端连接上等待副本确认。
    if err := client.Set(ctx, "order:1001", "paid", 5*time.Minute).Err(); err != nil {
        return fmt.Errorf("写入主节点失败: %w", err)
    }

    // 1500 是毫秒；返回值是实际确认这批写入的副本数。
    acknowledged, err := client.Wait(ctx, 2, 1500*time.Millisecond).Result()
    if err != nil {
        return fmt.Errorf("等待副本确认失败: %w", err)
    }
    if acknowledged 

这里的 2 不是“总共有两个副本”的配置，而是本次最多等待两个副本确认的目标。实际连接数不足、复制链路变慢或超时，都可能让返回值小于目标，因此不能只判断命令有没有报错。

返回值怎样区分达标、部分确认和超时

WAIT 返回一个整数。最稳妥的判断是把它和期望的 numreplicas 比较：

超时本身不等于“主节点没有写入”。主节点写入已经发生，只是确认数没有在给定时间内达到目标。若业务要求幂等重试，应使用业务唯一键或版本号，避免把一次“确认不足”误当成“完全没写”而重复扣款、重复发货。

把 WAIT 放进可降级的写入工作流

一个实用的工作流是：先根据数据重要程度决定目标副本数，再根据接口预算设置毫秒级超时；写入和 WAIT 结束后比较返回值，达标才给调用方返回“已确认”，未达标则进入重试、补偿或人工可追踪状态。不要设置无限等待来掩盖故障，除非调用方明确允许请求长期阻塞。

WAIT 还不能代替持久化策略。若需要等待 AOF 写盘，应单独评估 Redis 7.2 引入的 WAITAOF；如果目标是故障转移后的数据安全，还要一起检查主副本拓扑、Sentinel 或 Cluster 的故障转移策略，以及主副本的持久化配置。WAIT 的价值是提高确认副本已收到写入的概率，不能单独给出“永久不丢数据”的承诺。

最后可以把下面四项写进代码评审清单：是否同一连接发送写入和 WAIT；是否比较整数返回值；未达标时是否幂等；对外文案是否避免把副本确认写成持久化或强一致。

常见问题

WAIT 的 timeout 单位是什么？是毫秒，0 表示一直等待。

返回值达到目标后就一定不会丢数据吗？不是。它只说明当前连接此前的写入已被相应数量的副本确认，故障转移和持久化仍有独立风险。

连接池里怎样避免用错连接？让负责写入的客户端调用 WAIT，或在客户端库中明确把两次命令绑定到同一连接；不要只依赖“从同一个连接池取出”这种不透明假设。