重写缓冲区的作用
重写由子进程完成，它写出的是「重写开始那一刻」的数据视图。重写期间新到的写命令如果只留在旧 AOF 里，切换完成后就会丢，所以 Redis 同时把这段窗口内的写命令追加到重写缓冲区，子进程完成后把缓冲区内容补写到新文件，再原子地切换到新文件。缓冲区越大，切换瞬间的追加耗时与内存占用都随之上升。
基本信息
| 目的 | 覆盖重写窗口内产生的增量写命令 |
|---|---|
| 相关内存 | 客户端输出缓冲与重写缓冲区共同占用 |
| 完成动作 | 子进程结束、追加缓冲、重命名切换 |
| 观察入口 | INFO persistence 与 INFO memory |
| 风险点 | 窗口越长、写入越猛，缓冲越大 |
典型使用场景
- 重写期间观察到内存明显上涨，需要判断是否与缓冲区有关
- 写入高峰执行重写后出现切换卡顿，评估是否需要调整重写时机
- 容量规划时把重写缓冲纳入内存余量，避免顶到上限触发淘汰
- 排查重写完成后数据完整性，确认窗口内的写没有丢
- 评估 BGREWRITEAOF 的成本，选择在低峰执行
观察示例
观察示例
redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_last_bgrewrite_status'
redis-cli INFO memory | grep -E 'used_memory:|mem_not_counted_for_evict'
redis-cli BGREWRITEAOF # 手工触发，便于对比前后指标
tail -f /var/log/redis/redis.log | grep -i rewrite # 观察重写起止时间观察项与判读
| 观察项 | 含义 | 异常表现 |
|---|---|---|
| aof_rewrite_in_progress | 是否有重写正在执行 | 长时间为 1 说明子进程被拖慢 |
| used_memory 曲线 | 含缓冲区在内的总占用 | 重写期间明显抬升属预期 |
| 重写耗时 | 从开始到切换完成的时长 | 耗时越长缓冲越大，切换越重 |
| 切换后校验 | 新文件是否可正常加载 | 切换失败会保留旧文件并记录状态 |
重写窗口越长、写入速率越高，需要补写的历史命令就越多，内存峰值与切换耗时同步上升，把重写安排在低峰能同时缓解这两个问题。
观察不能只看「是否在重写」这一个标志，还要结合内存曲线与重写耗时的变化，才能判断缓冲带来的真实压力。