redis 7.0 的 multi-part aof 彻底移除 aof_rewrite_buf，改用 base.aof（全量快照）与多个 incr-*.aof（增量日志）分离存储，主进程直接落盘增量命令，无需内存缓冲，避免 oom 和重写卡顿。

Redis 7.0 不再需要 aof_rewrite_buf_size 参数，因为它根本就删掉了这个缓冲区——aof_rewrite_buf 被彻底移除，不再是架构的一部分。

为什么旧版必须用 aof_rewrite_buf

在 Redis 6.x 及更早版本中，AOF 重写（BGREWRITEAOF）依赖子进程生成新 AOF 文件。但主进程不能停，它得继续处理写请求。为了不丢数据，主进程必须把重写期间产生的新命令缓存在内存里，等子进程写完临时文件后，再把这部分缓存追加进去。

这个缓存就是 aof_rewrite_buf，它没有固定上限，靠操作系统内存硬扛。高写入场景下极易暴涨，引发 OOM；重写结束时还要一次性刷盘，造成主线程卡顿。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 它是纯内存结构，无法配置大小限制（aof_rewrite_buf_size 并不存在于任何 Redis 版本的配置项中——这是个常见误解，实际从未提供过该参数）
• 日志里出现 Failed to allocate rewrite buffer 或 OOM in aof_rewrite_buf 就是它爆了
• 即使你调低 auto-aof-rewrite-percentage，也拦不住突发流量瞬间打满缓冲区

MP-AOF 是怎么绕开 rewrite_buf 的

Redis 7.0 的 multi-part AOF 把“重写”和“实时写入”解耦：不再让子进程承担全部写入压力，而是让主进程直接落盘增量日志。

• base.aof（或 base.rdb）由子进程生成，只做一次，完成后即冻结
• 所有重写开始后的新增命令，主进程直接写入新的 incr-*.aof 文件，不经过任何中间内存缓冲
• 没有 aof_rewrite_buf，自然也不需要它的“大小控制”逻辑
• 重写完成时无需追加缓冲、无需 rename 全量文件，只需更新 manifest 清单文件即可切换生效

如何确认你的实例已摆脱 rewrite_buf 依赖

关键不是看配置项有没有，而是看运行时行为是否已切换到 MP-AOF 架构。

• 检查配置：config get aof-use-rdb-preamble 返回 no，说明启用纯 MP-AOF；若返回 yes，则退回到 4.0–6.x 的混合模式，仍可能触发旧式重写逻辑
• 观察 AOF 目录：ls /var/lib/redis/*.aof 应看到 base.aof + incr-*.aof + manifest，而不是单一的 appendonly.aof
• 监控日志：tail -f /var/log/redis/redis-server.log 中出现 Creating new incr AOF file 或 Switching to new AOF manifest 即为 MP-AOF 正常工作
• 内存指标：INFO memory 中的 mem_clients_normal 和 mem_clients_slave 不会因 AOF 重写而突增——因为没 rewrite_buf 了

真正容易被忽略的是：MP-AOF 的可靠性不取决于某个缓冲区是否够大，而取决于 manifest 文件的原子写入和 incr-*.aof 的 fsync 粒度。一旦 manifest 损坏或未正确持久化，整个 AOF 链就不可恢复——这比旧版 rewrite_buf 溢出更隐蔽，也更难排查。