Redis AOF 重写期间磁盘峰值该怎样预估

Redis AOF 重写时，磁盘峰值不能只看当前的 aof_current_size。更稳妥的预算是：保留当前 AOF 占用，再为重写生成的 base AOF、重写期间继续到来的增量写入，以及文件系统安全余量预留空间。Redis 7 采用多段 AOF 后，旧 base、增量文件和新一轮重写产物会在切换前短暂共存，因此“数据集有多大”不是足够的估算依据。

先把 AOF 重写期间会共存的文件算清楚

Redis 收到 BGREWRITEAOF 后，会在后台生成一份更短的当前数据集表示，同时继续接收客户端写入。切换完成前，旧持久化内容不能立即删除，新产物也还没有完全落盘。Redis 7 以后，AOF 由 manifest 管理的 base 文件和增量文件组成，估算时应把目录里的实际文件总量作为“当前占用”，而不是只盯着某一个文件名。

用四个量建立可复用的峰值估算式

先在业务低峰和高峰各采一次持久化信息。重点不是得到一个漂亮的固定倍数，而是记录一次重写实际产生了多少新文件、用了多久、期间增加了多少写入。

# 读取 AOF 当前大小、基线大小和重写状态
redis-cli INFO persistence | grep -E 'aof_current_size|aof_base_size|aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status'

# 统计 AOF 目录在文件系统上的实际占用；路径按 appenddirname 调整
du -sh /var/lib/redis/appendonlydir
df -h /var/lib/redis

可以把预算写成：峰值预算 ≈ 当前目录占用 + 重写新 base 估算值 + 写入速率 × 重写时长 + 安全余量。新 base 的估算值最好来自最近一次成功重写后的目录大小；首次规划时可用数据集的磁盘化实测值作为保守近似，而不要直接把 used_memory 当作文件大小。安全余量至少覆盖一次慢重写和文件系统预留，业务写入波动明显时再加一个高峰系数。

不要把“当前大小”误当成“重写峰值”

例如目录当前占用 18 GB，最近一次重写生成的 base 文件为 7 GB，重写期间写入速率按高峰观测为 20 MB/s，预计最慢重写 180 秒，那么增量预算约为 3.5 GB。若再预留 25% 的波动和运维余量，容量下限约为 (18 + 7 + 3.5) × 1.25 = 35.6 GB。这只是规划示例，不是 Redis 的固定公式；真实值要用多次重写的最大值校准。

Redis 官方还提醒，AOF 与 RDB 都启用时，后台持久化任务不会无条件并发启动；重写可能排队。也就是说，磁盘峰值和重写耗时必须按实际调度窗口测量，不能拿一次理想低负载结果覆盖全天高峰。

发布前用状态和空间检查收口

如果可用空间已经接近预算下限，先降低写入波动、迁移持久化目录或扩容磁盘，再调整自动重写阈值；单纯把阈值调大，只是延后重写，并没有消除新旧文件共存的需求。备份时还要避免在重写过程中直接复制未稳定的 AOF 集合，按官方文档先暂停自动重写并确认 aof_rewrite_in_progress=0。

常见问题

AOF 重写一定需要两倍当前磁盘吗？

不一定。新 base 的大小取决于当前数据结构和命令重放结果，写入增量又取决于重写时长；两倍只能当粗略告警线，不能替代实测。

aof_base_size 能直接当新文件大小吗？

它更适合作为最近一次重写的基线，不能保证下一次相同。数据结构、过期键和写入模式变化后，应重新采样目录总量。

磁盘快满时可以手动 BGREWRITEAOF 吗？

不建议。先确保预算有余量并检查是否已有后台持久化任务；否则失败重写虽不会破坏旧 AOF，却可能加重磁盘压力。