旧版aof重写卡顿的根本原因是fork子进程复制页表叠加aof_rewrite_buf缓冲区无上限膨胀，导致内存、锁竞争与i/o尖峰三重压力；multi-part aof通过分离base快照与incr增量文件、消除rewrite_buf、分散fsync，将rss增长压至几十mb并降低p99延迟60%以上。
Redis 7.0 默认启用 Multi-part AOF，不是为了“更时髦”，而是它真能解决旧版重写时主线程卡顿、延迟飙升、甚至 OOM 的实际问题。
重写期间主线程卡顿的根本原因是什么
旧版（6.x 及之前）AOF 重写必须 fork 子进程，子进程需要完整复制主进程内存页表；同时主进程持续写入 aof_rewrite_buf 缓冲区。高写入场景下，这个缓冲区会无上限膨胀，导致：
- 内存分配频繁，碎片加剧，GC 压力上移
- 子进程消费慢 → 主进程等待锁 →
aof_rewrite_buf写入阻塞 - 重写结束前，主进程还得把整个
aof_rewrite_buf同步追加到新文件末尾，I/O 集中爆发
这三者叠加，P99 延迟常突增 200ms+，业务明显感知抖动。
Multi-part AOF 怎么绕过 fork 和 rewrite_buf
它把“全量快照”和“增量日志”物理分离，不再依赖单次大 rewrite：
-
base.aof（或*.base.rdb）只在真正需要全量快照时生成，由子进程完成，但频率大幅降低 -
incr-*.aof文件由主进程直接写入磁盘，不经过内存缓冲区 ——aof_rewrite_buf彻底消失 - 重写逻辑退化为“滚动生成新 incr 文件”，主进程只需切换文件描述符，无大块内存拷贝
实测：10GB 数据集下，重写期间主进程 RSS 增长稳定在 40MB 左右，而非翻倍至 20GB+。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么 aof-use-rdb-preamble no 是关键开关
这个配置决定 Redis 走哪条持久化路径：
-
CONFIG GET aof-use-rdb-preamble返回yes→ 回退到 6.x 混合模式（RDB 头 + AOF 尾），仍用单文件 +aof_rewrite_buf -
no→ 真正启用 Multi-part，目录下出现base.aof、incr-00000001.aof、manifest
注意：appenddirname 必须显式配置且独立于 dir，否则文件混放可能被运维脚本误删 —— 这是上线后最容易被忽略的故障点。
everysec 模式下延迟波动下降 60% 怎么来的
旧版 appendfsync everysec 在重写时，aof_rewrite_buf 同步压力会拖慢主线程 fsync 调度；Multi-part 把 fsync 分散到多个小 incr-*.aof 文件：
- 每个
incr文件写入后立即fdatasync，耗时稳定在毫秒级 - 不再有“最后一秒攒一堆命令等同步”的尖峰
- 即使某个
incr文件损坏，manifest可跳过它继续加载，恢复链不中断
真正影响落地效果的，往往不是功能是否开启，而是 manifest 文件是否被备份、appenddirname 磁盘空间是否被监控脚本清空 —— 这些细节比参数调优更值得花时间检查。
