MP-AOF不再需要aof_rewrite_buf，因其将快照与增量日志分离：base.aof由轻量子进程生成后冻结，新增命令由主线程直接写入incr-*.aof，无需中间缓冲区。
MP-AOF 不再需要 aof_rewrite_buf，因为它根本没这个缓冲区
旧版 AOF 为什么非得用 aof_rewrite_buf
Redis 6.x 及之前版本的 bgrewriteaof 必须 fork 子进程，主进程在重写期间持续接收写命令，但不能直接写入新 AOF 文件（子进程还没写完），所以所有新增命令必须暂存在内存缓冲区 —— 就是 aof_rewrite_buf。这个缓冲区没有大小限制，高写入下可能暴涨到 GB 级，导致：
- 内存 RSS 突增，触发 OOM Killer
- 主进程写入
aof_rewrite_buf时需加锁，和子进程消费竞争，造成延迟毛刺 - 重写结束前，主进程还得把整个
aof_rewrite_buf追加进新文件，I/O 集中爆发
MP-AOF 是怎么绕开缓冲区的
Redis 7.0 的 Multi-part AOF 把“快照”和“增量日志”彻底拆开，不再依赖单次大重写：
-
base.aof（或*.base.rdb）由轻量级子进程生成，只做一次，完成后即冻结 - 所有重写开始后的新增命令，由主线程直接写入新的
incr-*.aof文件，不经过任何中间内存缓冲 - 主线程不等子进程，也不攒批，每条命令追加后立即落盘（受
appendfsync控制） - 子进程只负责生成 BASE，不处理增量，生命周期极短，几乎不产生 COW 压力
怎么确认你真没用 aof_rewrite_buf
不能只看 Redis 版本号，关键看运行时行为是否已切换到 MP-AOF 架构：
- 执行
CONFIG GET aof-use-rdb-preamble，返回必须是no；若为yes，说明退回到 4.0–6.x 混合模式，仍可能触发旧式重写 - 检查
dir或appenddirname目录：应存在base.aof（或*.base.rdb）、至少一个incr-*.aof、以及appendonly.aof.manifest - 日志中应出现
Creating new incr AOF file或Starting automatic rewriting of AOF on base.aof size
真正容易被忽略的是：即使升级到 Redis 7.0，只要 aof-use-rdb-preamble yes，就等于关掉了 MP-AOF，aof_rewrite_buf 依然存在，所有旧版问题照旧发生。
