Redis AOF理解重写期间的磁盘与延迟的实现方法

Redis AOF 重写的核心不是把旧文件原地压缩，而是根据当前内存数据生成一份更短的基线，同时继续接收客户端写入。磁盘空间在这段时间短暂增加、写延迟出现波峰，并不一定代表数据损坏；更常见的原因是 fork、Copy-on-Write、临时文件和 fsync 叠加。处理时应先看重写状态与磁盘余量，再调整触发阈值和同步策略。

AOF 重写到底在磁盘上做了什么

AOF 会记录改变数据集的写命令。一个计数器被自增很多次，日志里可能有很多条命令，但恢复当前值并不需要保留每一次中间变化。BGREWRITEAOF 会让后台子进程按当前数据集写出最短的重建序列；自动重写则在 AOF 达到配置条件时触发。

Redis 7.0 起，AOF 使用多部分布局：最多一个 base 文件、若干 incremental 文件，以及描述文件集合的 manifest。重写时父进程打开新的增量文件接住实时写入，子进程生成新的 base；完成后通过临时 manifest 原子切换。这个过程解释了为什么不能只盯着一个旧的 appendonly.aof 文件判断空间。

磁盘增长和延迟抖动分别从哪里来

重写初期通常需要同时容纳旧文件、新 base、增量写入和临时元数据，因此磁盘使用率可能先升后降。子进程由 fork 创建，父子进程共享页面；当主进程继续修改数据时，操作系统会发生 Copy-on-Write，内存压力也可能传导到延迟。写入量越大、数据结构越复杂，重写阶段越需要预留余量。

fsync 是另一条延迟链路。appendfsync always 把耐久性放在首位，但每批写入都可能等待同步；everysec 通常是平衡选项；no 把刷新交给操作系统，性能和数据丢失窗口都更依赖主机。不要只看到延迟升高就把 fsync 关闭，先确认是否是磁盘带宽、fork 或内存回收在成为瓶颈。

用配置把重写频率和数据安全分开处理

配置时先明确业务能接受的丢失窗口，再决定 appendfsync。自动重写阈值则回答另一个问题：日志相对上次重写增长到什么程度，才值得付出一次后台重写成本。示例只展示思路，数值应结合磁盘余量、写入速率和恢复时间压测。

# 先选择可接受的数据丢失窗口，再决定 fsync 频率
appendonly yes
appendfsync everysec

# AOF 相对上次重写增长达到 100% 且超过 64 MB 时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 重写期磁盘紧张时可暂时关闭自动触发，处理完成后恢复
# auto-aof-rewrite-percentage 0

如果重写与 RDB 快照同时争用磁盘，Redis 会避免两个后台持久化任务并行执行，显式请求的重写可能进入 scheduled 状态。生产环境不要用频繁手工执行 BGREWRITEAOF 来“压缩一下”，应让增长比例、最小规模和可用空间共同决定时机。

用 INFO persistence 判断重写是否真的影响服务

排查时把一次观察拆成开始前、进行中和完成后三个时间点，至少记录磁盘可用空间、实例内存、写入速率和下面这些字段：

# 只读取持久化区，便于把重写状态与延迟采样对齐
redis-cli INFO persistence | grep -E 'aof_(rewrite|last_bgrewrite|last_cow)'

# 手工触发前先确认没有正在运行的持久化子进程
redis-cli BGREWRITEAOF

观察到延迟抖动时，先区分“重写正在进行”和“上次重写失败”。前者通常需要等任务完成或降低写入压力；后者要检查权限、空间、文件系统和进程日志，不能靠重复触发解决。

常见问题

重写期间磁盘空间为什么会突然变大？

因为旧基线、新 base、实时增量和临时清单可能同时存在。空间规划至少要覆盖一次重写峰值，不要只按最终 AOF 大小预留。

把 appendfsync 改成 no 能彻底消除延迟吗？

不能。它只减少 fsync 等待，fork、Copy-on-Write、磁盘写带宽和内存压力仍可能造成抖动，而且故障时的数据丢失窗口更难控制。

如何确认重写已完成？

使用 INFO persistence 查看 aof_rewrite_in_progress=0、aof_rewrite_scheduled=0，并确认 aof_last_bgrewrite_status=ok，再结合磁盘使用率回落判断。

实际运行中，AOF 重写更像一次需要容量预算的后台迁移：先保证旧数据仍可恢复，再观察新基线的生成速度，最后按业务对耐久性和延迟的取舍调整策略。这样比盲目关闭重写或 fsync 更容易保住服务稳定性。