redis 7.0不再内存翻倍，因其弃用fork+aof_rewrite_buf旧模式，改用multi-part aof：base文件由轻量子进程生成，incr文件由主线程直写磁盘，aof_rewrite_buf彻底消失，rss增长稳定在几十mb。
Redis 7.0重写内存翻倍的根源是fork + aof_rewrite_buf
旧版AOF重写（bgrewriteaof）必须fork子进程，而Linux的COW机制会让主线程修改任意内存页时触发整页复制；同时主进程所有新写入命令都塞进aof_rewrite_buf——这个缓冲区无上限增长，和COW叠加后，used_memory_rss常在几秒内翻倍，直接触发OOM Killer。你看到dmesg | grep "killed process"里有redis-server，基本就是它。
Multi-part AOF如何绕过fork和rewrite_buf
它把“快照”和“增量”物理拆开，不再需要一次生成全量命令流：
-
base.aof（或*.base.rdb）由轻量级子进程生成，只做一次紧凑RDB快照，生命周期极短，COW压力微乎其微 -
incr-*.aof由主线程直接写磁盘，不经过内存缓冲区——aof_rewrite_buf彻底消失 - 重写退化为“滚动创建新incr文件”，主线程只需切换fd，无大块内存拷贝
实测10GB数据集下，重写期间RSS增长稳定在40MB左右，而非旧版动辄20GB+。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么aof-use-rdb-preamble no是关键开关
这个配置决定你走哪条路径：
- 若
CONFIG GET aof-use-rdb-preamble返回yes，说明你实际用的是Redis 6.x混合模式（RDB头+单AOF尾），仍依赖aof_rewrite_buf，没真正启用Multi-part - 返回
no才是真MP-AOF，目录下应出现base.aof、incr-*.aof、manifest - 漏配
appenddirname会导致文件混放，运维脚本按*.aof通配符清理时可能误删manifest，这是上线后最隐蔽的故障点
确认是否真在用Multi-part AOF的三要素
不能只看版本号，默认开启≠真生效：
- 配置：执行
CONFIG GET aof-use-rdb-preamble，结果必须是no - 文件：检查
appenddirname目录，必须存在base.aof（或*.base.rdb）、至少一个incr-*.aof、以及manifest - 日志：启动或重写时应有
Creating new incr AOF file或Starting automatic rewriting of AOF on base.aof size
最容易被忽略的是manifest文件的完整性——它只有几百字节，却是整个恢复链的唯一入口；一旦损坏，Redis启动直接abort，且无法自动降级。
