Redis AOF 重写期间延迟抖高怎么定位：BGREWRITEAOF、写时复制与磁盘余量

线上 Redis 的命令平均耗时没有明显变化，但 P99 每隔一段时间就抬头，慢日志里又找不到一个足以解释波动的大命令。若实例启用了 AOF，后台重写正是需要先排除的因素：它会启动子进程整理日志，主进程还要继续接收写入，期间可能同时承受 fork 停顿、写时复制和磁盘写入压力。

先看 INFO persistence 判断重写是否正在进行，再把延迟峰值和 RSS、磁盘余量、AOF 增量放在同一条时间线上；不要一看到延迟就直接调大重写阈值。

先把延迟峰值和 AOF 状态对上

Redis 的 AOF 重写不是把旧文件原地压缩，而是由后台子进程生成一份更紧凑的文件，主进程继续把新写入追加到重写缓冲区。等子进程完成后，Redis 再把这段增量合并进去。因此，BGREWRITEAOF 返回“已开始”只代表任务被接受，不能当作性能安全证明。

值班时先取一份基线，再每隔 5 秒采集一次。不要只执行一次命令就下结论：

redis-cli INFO persistence | egrep 'aof_rewrite|aof_last_bgrewrite|aof_current_size|aof_base_size'
redis-cli INFO memory | egrep 'used_memory_rss|used_memory_peak|mem_fragmentation_ratio'
df -h /var/lib/redis

重点字段可以这样读：

• aof_rewrite_in_progress 为 1，说明子进程正在重写；aof_rewrite_scheduled 为 1，则说明当前有别的持久化子进程，重写被排队。
• aof_last_bgrewrite_status 应在结束后回到 ok。如果是 err，先处理失败原因，不要反复触发。
• aof_rewrite_buffer_length 持续增长，表示主进程接收的新写入超过了重写合并速度。

fork、写时复制和磁盘分别会制造什么症状

fork 造成的是短促停顿

子进程启动前需要复制进程的页表。数据集越大，fork 的成本越容易在延迟曲线上形成尖峰。它通常表现为某几个采样点突然变慢，随后恢复；如果每次重写都在相近时间出现尖峰，应该把 fork 时间、实例 RSS 和重写开始时间放在一张图上看。

写时复制会让内存先涨起来

重写子进程读取旧数据时，主进程仍然在改写内存页。被改写的页需要保留一份副本，RSS 可能明显高于平时。Redis 官方管理文档提醒，写入密集实例在 RDB 保存或 AOF 重写期间可能使用接近平时两倍的内存。内存余量不足时，先别急着调参数，先确认是否存在 swap、容器内存限制或内核回收压力。

磁盘瓶颈会把尾部拖长

如果 CPU 和内存没有明显变化，但 aof_rewrite_buffer_length、磁盘写入等待和 P99 一起变高，问题更像是磁盘吞吐或 fsync 竞争。AOF 目录要留出旧文件、新文件和增量合并的空间，不能只按当前 AOF 文件大小预留。

用一组小实验把根因分开

测试最好在业务低峰、可回退的副本或压测实例进行。生产环境只做观测和经过审批的单次触发。先记录业务 QPS、P50/P99、used_memory_rss、磁盘可用空间和重写前后的 AOF 大小，然后再执行：

redis-cli BGREWRITEAOF
redis-cli INFO persistence | egrep 'aof_rewrite_in_progress|aof_rewrite_buffer_length|aof_last_bgrewrite_status'

若触发后只有一个很短的尖峰，随后各项指标稳定，优先怀疑 fork；若 RSS 随写入量持续爬升并接近容器上限，优先处理写时复制的内存余量；若重写持续时间变长、磁盘 await 和增量缓冲一起上升，则要检查磁盘类型、挂载配额和同盘日志任务。

这里有一个容易误判的情况：重写期间延迟上升，不代表 AOF 一定是唯一原因。慢命令、网络抖动和 CPU steal 也可能恰好同窗发生。用同一时刻的 SLOWLOG GET、系统 CPU steal 和网卡丢包数据做反证，能避免把所有问题都归给持久化。

参数调整要围绕可用内存和磁盘余量

自动重写通常由 auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size 控制。前者决定当前 AOF 相对上次基线增长到什么比例后触发，后者防止小文件频繁重写。调大阈值可以减少重写次数，却会让 AOF 变得更大、恢复时间变长；调小阈值则可能把 fork 和磁盘压力变成高频事件。

实操上先做三件事：给 Redis 进程和子进程留出明确的内存余量；把 AOF 所在磁盘的可用空间纳入告警；将重写时长、失败状态和缓冲区长度纳入发布验收。不要把关闭 AOF 当成默认修复，除非业务已经明确接受数据持久性变化，并且完成了配置文件同步与恢复演练。

重写完成后的验收与回退

验收至少覆盖一次完整的重写周期：aof_rewrite_in_progress 回到 0，aof_rewrite_scheduled 回到 0，aof_last_bgrewrite_status 为 ok，重写缓冲区回落，业务 P99 在相同流量下恢复到基线附近。还要确认 AOF 目录的文件数量、大小和权限没有异常。

如果重写失败，Redis 会保留旧 AOF，不要在故障现场删除旧文件或连续重试。先保存 INFO persistence、系统日志、磁盘错误和剩余空间，再按容量、权限、子进程退出码逐项排查。需要回退参数时，先用 CONFIG SET 做受控验证，再把最终配置写回 redis.conf，避免重启后恢复旧值。

常见问题

重写期间延迟一定会升高吗？

不一定。小数据集、空闲写入和足够快的磁盘可能几乎没有可见影响；是否抖高取决于数据集大小、写入速率、内存余量和磁盘竞争。

看到 aof_rewrite_in_progress 就能确认根因吗？

不能。它只证明重写正在进行，还需要对照 RSS、缓冲区、磁盘等待、慢日志和 CPU steal，才能区分 fork、写时复制与外部 I/O。

为什么调大 auto-aof-rewrite-percentage 后问题没消失？

它只影响触发频率，不会降低单次重写的 fork、内存或磁盘成本。如果单次重写本身已经超出实例余量，减少次数不能替代扩容或拆分持久化压力。

把 AOF 重写纳入日常巡检

Redis AOF 的稳定性不在某个孤立参数里，而在“重写是否按计划完成、期间有没有耗尽内存和磁盘、业务尾延迟是否可接受”这条证据链里。将重写状态、缓冲区、RSS、磁盘余量和 P99 放进同一张面板，每次版本变更或容量增长后做一次可控重写，往往比事后追一条尖峰日志更省时间。