写入到底落盘了没
客户端写完一条关键数据，怎么确认它真的落到磁盘上？Redis 7.2 起提供 WAITAOF：它等待本地 AOF 与指定数量副本的 AOF 完成 fsync，然后返回实际达成的数量。它不修改数据，只负责「等一个确认」，适合订单、支付这类需要明确持久性承诺的写路径。
基本信息
| 语法 | WAITAOF <numlocal> <numreplicas> <timeout>，超时单位为毫秒 |
|---|---|
| 返回 | 两个整数：本地已落盘数量（0 或 1）与被确认的副本数量 |
| 前提 | 本地 appendonly yes；副本也要开启 AOF 才能被计入 |
| 版本 | Redis 7.2 起 |
典型使用场景
- 关键写入落盘后再向业务返回成功，避免「已提交但没落盘」
- 上线前验证 AOF 与副本 AOF 配置是否真的生效
- 演练中测量本地与副本 fsync 的实际延迟
- 排查「客户端报失败但数据其实还在」这类持久性争议
- 与 WAIT 配合，区分「已同步到副本」和「已落盘」两件事
写法与核对
写法与核对
# 关键写入后确认本机已 fsync，且至少有 1 个副本的 AOF 也已完成
redis-cli SET order:1001 paid
redis-cli WAITAOF 1 1 100
# 只要求本机落盘，不要求副本确认
redis-cli WAITAOF 1 0 100
# 先确认两端 AOF 都真的开着，否则副本计数永远是 0
redis-cli CONFIG GET appendonly
redis-cli INFO persistence | grep -E 'aof_enabled|aof_last_write_status'参数与返回读法
| 项目 | 含义 | 注意点 |
|---|---|---|
| numlocal | 要求本地落盘的数量 | 只能取 0 或 1 |
| numreplicas | 要求确认落盘的副本数 | 副本未开 AOF 时无法满足 |
| timeout | 超时毫秒数 | 超时返回已达成数量，不报错 |
| 第一个返回值 | 本地已达成的数量 | 为 0 说明超时前本地都没落盘 |
| 第二个返回值 | 已确认副本数量 | 小于期望值说明副本侧没跟上 |
WAITAOF 基于实例当前已处理的写命令统计确认数，业务上通常这样用：先写、再等、根据返回的两个数字决定报成功还是重试，而不是指望它保证数据永不丢失。
每次写入都等落盘会显著抬高写延迟，副本 AOF 的 fsync 还取决于对端磁盘性能；只在真正需要持久性承诺的写路径上使用，并设置合理的超时。