这个开关解决什么
开启 AOF 后，主进程在后台重写期间仍会按 appendfsync 的节奏调用 fsync，磁盘压力大时这次调用会阻塞主线程，表现为写入延迟尖峰。no-appendfsync-on-rewrite 就是为这个场景准备的：设为 yes 后，重写进行期间主进程暂停 fsync，内核仍会把脏页写出去，只是不再强制等待落盘，代价是这段时间未落盘的数据在断电时可能丢失。
基本信息
| 取值 | no（默认）照常 fsync；yes 重写期间暂停 fsync |
|---|---|
| 生效范围 | 仅在后台重写进行期间，其他时间行为不变 |
| 收益 | 降低重写期的写入延迟抖动 |
| 代价 | 重写全程未落盘数据存在丢失窗口 |
| 关联配置 | appendfsync 的刷新策略决定常规节奏 |
典型使用场景
- 高写入实例在每次重写时都出现明显的延迟毛刺，需要评估是否开启
- 磁盘是延迟较高的网络盘或云盘，fsync 阻塞效应被放大
- 缓存型实例能容忍极少量数据丢失，用延迟优先换取稳定
- 压测中对比开启与关闭的延迟曲线，用数据支撑决策
- 配合低峰编排把重写安排在流量低谷，降低开关带来的风险
查看与调整
查看与调整
redis-cli CONFIG GET no-appendfsync-on-rewrite
redis-cli CONFIG SET no-appendfsync-on-rewrite yes # 延迟优先，接受重写期丢失窗口
redis-cli INFO persistence | grep aof_rewrite_in_progress # 确认当前是否正在重写
redis-cli CONFIG REWRITE # 写回配置文件持久生效取值对照
| 取值 | 重写期行为 | 适用判断 |
|---|---|---|
| no | 照常按秒 fsync | 丢失窗口最小，磁盘抖动时延迟可能尖峰 |
| yes | 重写期暂停 fsync | 延迟更平滑，重写全程数据有丢失风险 |
| appendfsync always | 每次写入都等落盘 | 该选项影响有限，因为本就在同步等待 |
这个选项只在后台重写期间起作用，重写之外的写入延迟不受它影响，不要指望它解决常规慢查询或大键问题。
若磁盘长期处于饱和状态，即使设为 no，fsync 也可能长时间阻塞主线程；真正要解决的是磁盘吞吐能力，而不是这个开关。