Redis AOF 重写期间延迟升高怎么判断

Redis 在 AOF 重写期间出现延迟升高，通常不能简单归因于“重写把 Redis 卡住了”。需要先确认重写是否正在进行，再把压力拆成 fork、写时复制（COW）、AOF 写入和 fsync。aof_rewrite_in_progress 只能说明状态，不能单独证明根因。

官方地址：https://redis.io/

最小排查顺序是：先看 INFO persistence，再对照 current_cow_size、aof_pending_bio_fsync、aof_delayed_fsync 和 Redis 延迟事件。重写结束后，再用 aof_last_bgrewrite_status 确认结果。

先确认延迟发生在 AOF 重写窗口

先抓取持久化区，而不是马上手动执行新的重写命令。下面的输出只用于观察当前实例状态：

# 查看 AOF 重写、耗时、COW 和 fsync 排队状态
redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_rewrite_scheduled|aof_current_rewrite_time_sec|current_cow_size|current_fork_perc|aof_pending_bio_fsync|aof_delayed_fsync|aof_last_bgrewrite_status'

# 间隔采样，比较重写状态与延迟曲线是否同时变化
watch -n 1 "redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|current_cow_size|aof_pending_bio_fsync|aof_delayed_fsync'"

重点看三个组合：重写进行中且 current_cow_size 持续变大，往往意味着写入造成的内存页复制压力；aof_pending_bio_fsync 或 aof_delayed_fsync 增长，说明写盘或同步出现排队；若这些值稳定而延迟仍升高，就要把注意力转向命令执行、网络或宿主机资源。

把“重写变慢”拆成四类证据

Redis 官方的持久化信息把重写过程拆成了几个可观察的面。aof_current_rewrite_time_sec 用来表示当前重写耗时，aof_last_rewrite_time_sec 可以与历史窗口比较；current_fork_perc 和 current_cow_size 则帮助判断 fork 后的页复制压力。

如果延迟尖峰和 aof_delayed_fsync 同步出现，应优先检查磁盘延迟、文件系统拥塞和 fsync 策略。若 COW 变大但 fsync 排队不明显，应检查实例内存余量、写入速率和 fork 时的内存压力。不要把 aof_rewrite_buffer_length 当成所有版本都存在的指标，Redis 7.0 起该字段已移除。

还可以使用 Redis 延迟监控关注 fork、aof-write、aof-write-pending-fsync、aof-rename 和 aof-rewrite-diff-write 等事件。它们比单一的平均响应时间更适合判断延迟究竟发生在进程创建、写入、同步还是重写收尾。

正在重写和已经结束，处理方式不同

如果 aof_rewrite_in_progress=1，不要因为业务延迟升高就连续执行 BGREWRITEAOF。已有重写时，命令不会替你排队出第二个重写；Redis 也会避免 AOF 重写与另一个持久化后台任务同时进行。此时应记录采样、确认磁盘和内存余量，并减少会放大压力的并发操作。

如果重写已经结束，先看 aof_last_bgrewrite_status 是否为 ok，再对照 aof_last_rewrite_time_sec 和业务延迟是否回落。状态正常但延迟不回落，说明 AOF 重写可能只是同窗发生的现象，继续排查慢命令、网络、CPU steal 或磁盘整体负载。

# 重写结束后只做结果确认，不重复触发重写
redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status|aof_last_rewrite_time_sec'

# 查看 Redis 延迟事件，帮助区分写盘与 fork 影响
redis-cli LATENCY LATEST

常见误区与排查清单

归纳起来，AOF 重写期间的延迟定位要把“状态”与“原因”分开：状态由 INFO persistence 确认，原因由 COW、fsync、fork 和延迟事件共同判断。这样既能避免误停持久化，也能在重写完成后及时发现真正的业务瓶颈。

相关问题

AOF 重写会阻塞 Redis 吗？

重写在后台生成新文件，但 fork、写入、同步和收尾仍可能带来延迟。是否明显取决于数据规模、写入量、内存和磁盘。

为什么重写结束了延迟还没有恢复？

重写可能只是时间上的伴随现象。应比较重写状态与延迟事件，并继续检查慢命令、网络和宿主机资源。