no-appendfsync-on-rewrite设为yes时，重写期间跳过fsync，AOF数据仅驻留page cache，最多丢失30秒写入，磁盘延迟下降但RPO恶化；默认no更安全，保障1秒RPO并保留自动升频兜底能力。
no-appendfsync-on-rewrite 不是“开或关”的简单选择，而是要在磁盘 IO 冲突与数据丢失风险之间做显式权衡。默认值 no 是安全起点，但生产中是否要改，取决于你能否接受重写期间最多 30 秒的数据丢失。
no-appendfsync-on-rewrite 设为 yes 时会发生什么
当 no-appendfsync-on-rewrite 设为 yes，且当前 appendfsync 是 everysec 或 always，Redis 主进程在 BGREWRITEAOF 或 BGSAVE 执行期间会完全跳过 fsync() 调用——等效于临时把 appendfsync 切成 no。
这意味着：
- AOF 缓冲区数据仅留在内核 page cache 中，由操作系统决定刷盘时机（通常 30–60 秒）
- 若此时 Redis 进程崩溃或机器断电，最多可能丢失最近 30 秒的写入（Linux 默认 dirty_expire_centisecs=3000）
- 磁盘 write wait 显著下降，主进程延迟（latency）更平稳，尤其在机械盘或高负载 SSD 上效果明显
- 该行为不改变
appendfsync配置本身，只是运行时临时降级
为什么默认值 no 更适合多数业务场景
no-appendfsync-on-rewrite 默认是 no，这不是保守，而是对数据边界负责。它确保：
- 即使
BGREWRITEAOF正在跑，每秒仍会执行一次fsync()（对应everysec），RPO 稳定在 1 秒内 - 不会因重写触发意外的数据丢失窗口，符合金融、订单、用户状态类业务的底线要求
- Redis 在检测到磁盘延迟突增时，会自动将刷盘策略临时升为
always（前提是该参数为no），这是关键的兜底机制 - 如果设为
yes，这个自动升频能力就失效了——你主动放弃了最后一道防线
哪些场景可以考虑设为 yes
只有同时满足以下全部条件，才建议将 no-appendfsync-on-rewrite 改为 yes：
- 业务能容忍 RPO > 10 秒，且有外部补救手段（如应用层双写 DB、消息队列落盘）
- Redis 节点磁盘 I/O util 持续 > 90%，
redis-cli --latency显示 p99 延迟频繁突破 5ms - 已关闭所有
save规则（避免BGSAVE与BGREWRITEAOF同时触发） - 使用的是混合持久化（
aof-use-rdb-preamble yes），降低 AOF 重写频率和体积 - 监控中明确看到
bgrewriteaof_in_progress与latest_fork_usec高峰重叠导致延迟毛刺
配置后必须验证的三个点
改完配置不能只重启就完事，务必确认：
- 用
CONFIG GET no-appendfsync-on-rewrite查看运行时值，避免CONFIG REWRITE漏写或被覆盖 - 观察日志中是否出现
Asynchronous AOF fsync is disabled during rewrite（设为yes时应出现） - 压测时对比
INFO persistence中的aof_delayed_fsync计数：设为yes后该值应趋近于 0，而no下可能周期性上涨
真正难的不是改这个参数，而是判断你的业务到底属于“丢了 30 秒数据会出 P0 故障”，还是“延迟抖动 50ms 就触发超时熔断”。这没法靠文档抄答案，得从监控曲线和故障复盘里找依据。
