redis 7.0 不再需要 aof_rewrite_buf，因其废弃传统重写，改用 multi-part aof：新增命令直接异步追加至.incr.aof文件，base文件仅存快照，合并由后台线程完成，内存占用稳定在几十mb。
Redis 7.0 不再需要 aof_rewrite_buf，因为它根本不再做传统意义上的 AOF 重写。
旧版 AOF 重写为什么必须依赖 aof_rewrite_buf
Redis 6.x 及之前版本的 bgrewriteaof 本质是 fork 子进程 + 全量 dump 内存数据。主进程在重写期间产生的新写命令，无法被子进程感知（COW 隔离），所以必须靠一块独立内存缓冲区 —— aof_rewrite_buf —— 来暂存这些增量。这块缓冲区会随写入压力线性增长，没有上限，OOM 风险真实存在。
常见错误现象包括：
- 重写过程中 Redis 进程 RSS 突增数 GB，甚至触发系统 OOM Killer
-
INFO memory显示used_memory_rss比used_memory高出一倍以上 - 日志中反复出现
WARNING: aof_rewrite_buffer is growing（某些 patched 版本）
Multi-part AOF 是怎么绕开 aof_rewrite_buf 的
它把“重写”这个动作从「重建历史」变成了「滚动合并」：BASE 文件（如 appendonly.aof.1.base.rdb）只存当前快照，INCR 文件（如 appendonly.aof.2.incr.aof）只追加命令。新增写入直接落盘到最新 INCR，不经过任何大块内存中转。
关键变化在于：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不再 fork 子进程做全量 dump，也就没有“子进程看不到新命令”的问题
- 增量命令由
aof-write-thread异步刷盘，缓冲区仅用于暂存待写入磁盘的几 KB~MB 命令文本 - 后台合并（
aof-rewrite-diff）只读取少量 INCR 文件内容，内存占用稳定在几十 MB 级别 -
aof_rewrite_buf这个变量在 Redis 7.0 源码中已被彻底移除
如何确认你的实例真的不用 aof_rewrite_buf 了
运行以下命令并检查返回值：
CONFIG GET aof-use-rdb-preamble
如果返回 no，说明启用纯 Multi-part 模式；若为 yes，则退化回 6.x 混合模式，仍可能用到旧缓冲机制。
再检查数据目录：
- 存在
*.base.rdb和*.incr.aof文件 → Multi-part 已激活 - 只有单个
appendonly.aof→ 仍在旧模式，或升级后未触发重写 - 存在
appendonly.aof.manifest→ 必定是 Multi-part，该文件是恢复入口
注意：aof-use-rdb-preamble no 是硬性前提，哪怕你用的是 Redis 7.0，只要配置里它是 yes，就等于主动关掉了 Multi-part 的核心优势。
