Redis WAIT 怎样等待副本确认写入

我在给 Redis 主库写入关键状态时，最容易混淆的不是命令怎么写，而是“主库返回 OK”和“副本已经收到”并不是同一件事。WAIT 能把这两个时刻之间的确认等待显式化：它等待当前连接此前写入被指定数量的副本确认，再返回实际确认数。

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

先区分写入完成和副本确认

普通写命令返回成功，首先说明主库已经接受并处理了这次写入。Redis 复制默认是异步的，复制流还需要传给副本并由副本确认。WAIT 的判断范围是当前连接中、出现在 WAIT 之前的写命令；它不是对所有客户端最近写入做全局扫描。

官方实现会记录客户端执行写命令时对应的复制流偏移。调用 WAIT 时，Redis 检查有多少副本已经确认这个偏移或更大的偏移。因此，关键写入和 WAIT 最好放在同一条连接上，连接切换会让“当前连接的此前写入”这个语义变得不清楚。

按副本数和毫秒超时发送 WAIT

命令格式很短，但两个参数决定了等待成本和业务含义。numreplicas 是至少要确认的副本数量，timeout 是最大等待时间，单位为毫秒。把等待时间写进方案时，我会同时记录写入耗时、WAIT 耗时、返回副本数和超时比例，而不是只看整体请求平均值。

# 先写入关键状态，再等待至少 1 个副本确认，最多等待 500 毫秒
redis-cli SET order:1001 paid
redis-cli WAIT 1 500

# 需要 2 个副本确认；timeout 为 0 表示一直等待，生产环境要谨慎使用
redis-cli SET order:1001:receipt ready
redis-cli WAIT 2 0

上面的两组命令是使用示例，不代表本机已经运行出对应返回值。实际等待时，副本数量、网络往返、复制积压和主库负载都会影响结果。把 timeout 设为无限并不会消除复制故障，反而可能让业务请求长期占住连接。

按返回值决定是否继续业务流程

WAIT 返回整数，表示当前连接此前写入实际被多少个副本确认。假设请求至少 2 个副本：返回 2 或更大，说明达到本次等待目标；返回 1，说明命令可能已经等到超时，但只有 1 个副本确认；返回 0，则表示在等待窗口内没有副本确认。

因此，程序应该比较返回值与自己的目标，而不是把“收到整数回复”直接当成成功。不同业务可以对部分确认采取记录告警、延迟响应、降级到主库读取或交给补偿队列等策略，关键是把策略和数据安全等级提前写清楚。

用指标看等待成本和安全边界

性能案例里，我会把一次请求拆成“主库写入时间”和“WAIT 额外等待时间”两段，再按返回副本数分桶。这样可以回答三个问题：副本通常多久确认、多少请求触发超时、部分确认是否集中发生在某个副本或网络时段。没有这些分桶，只看平均延迟，很容易把副本确认的尾部等待藏起来。

还要保留一个边界：Redis 官方明确说明，WAIT 不会让 Redis 成为强一致存储。即使多个副本已经同步收到写入，故障转移仍是尽力选择，已经同步的写入也可能丢失。它更适合表达“我愿意为更高的数据安全概率等待多久”，不适合写成“执行后绝不会丢数据”。

常见问题

WAIT 的 timeout 单位是什么？

单位是毫秒。0 表示无限等待；如果要保护接口尾延迟，通常应使用有限值，并处理返回值低于目标的情况。

WAIT 返回 1 就算成功吗？

只有当你的目标副本数是 1 时才算达到目标。返回值表示实际确认数量，必须与 numreplicas 比较。

WAIT 能保证主库故障后数据一定存在吗？

不能。它能提高故障转移时找到已接收写入副本的概率，但官方定义仍是尽力而为，不等同强一致或绝对不丢数据。

总结：把 WAIT 当成一次有上限的副本确认等待更准确。先在同一连接完成关键写入，再设置副本数和毫秒超时，最后比较实际返回值；同时用 P95/P99、超时比例和副本积压衡量代价，才能把“等待确认”真正接入业务决策。