WAIT 确认了什么
WAIT numreplicas timeout 会阻塞发起命令的这条连接，直到指定数量的副本确认收到了该连接此前发出的所有写命令，或者等到超时为止，返回实际确认的副本数量。它确认的是副本内存中已经应用，不保证副本自己已经落盘；超时也不会报错，只是把当前达到的数量返回给调用方，由业务自行判断。
基本信息
| 语法 | WAIT <副本数量> <超时毫秒> |
|---|---|
| 返回值 | 实际确认的副本数量 |
| 确认语义 | 副本内存中已应用，非持久化确认 |
| 超时行为 | 到点返回当前数量，不抛错 |
| 阻塞范围 | 只阻塞发起该命令的这条连接 |
典型使用场景
- 写入后需要确认已扩散到至少一个副本，降低单机故障时的丢失概率
- 关键操作后做一次确认再返回成功，让业务层的成功语义更接近实际
- 评估主从之间的同步延迟，观察确认耗时随写入量的变化
- 切换或维护前的安全检查，确认副本已跟上主库进度
- 压测中量化同步确认给写路径带来的额外延迟
使用示例
使用示例
redis-cli SET order:1001 paid # 先写入
redis-cli WAIT 1 1000 # 等待 1 个副本确认，最多等 1000 毫秒
redis-cli INFO replication | grep -E 'connected_slaves|slave0'
redis-cli -h <从库> GET order:1001 paid # 在副本上确认数据已可见返回值的读法
| 返回值 | 含义 | 应对 |
|---|---|---|
| 等于请求数量 | 目标数量副本均确认 | 按业务逻辑继续 |
| 小于请求数量 | 超时前只有部分副本确认 | 记录差异并在业务侧决定是否重试 |
| 为 0 | 没有任何副本确认 | 检查主从链路与副本状态 |
| 明显变慢 | 同步链路或副本出现瓶颈 | 排查副本负载与网络质量 |
把 WAIT 当作强一致复制来用会显著抬高写延迟，应按业务对丢失的容忍度选择性使用，不要在每个写操作后面都加。
确认数量统计的是所有连接正常的副本，并不指定是哪一个，副本数量变化会让同样的参数得到不同结果。