旧版单文件AOF的痛点在哪里
在Redis 7.0之前，AOF持久化采用的是单文件模式，也就是一个appendonly.aof文件承载所有的写命令记录。这个文件在正常情况下还好，但一旦触发AOF重写，问题就暴露出来了。旧版的重写流程是：主进程fork出一个子进程，子进程遍历内存数据生成一份全新的AOF文件，与此同时主进程把重写期间的新写入命令同时写入旧的AOF文件和一块重写缓冲区。等子进程完成后，主进程把重写缓冲区的内容追加到新文件，最后用新文件原子替换旧文件。
这套流程有两个明显的副作用。第一，fork本身在内存占用大的实例上会产生较大的延迟，因为fork需要复制页表，实例越大耗时越长，期间主进程是阻塞的。第二，重写期间所有写命令都要写两份（旧AOF文件加重写缓冲区），内存开销翻倍，磁盘IO压力也随之增大。另外旧版还存在一个著名的隐患：重写失败后如果处理不当，主进程可能直接崩溃，导致数据无法访问。
除了重写，单文件模式在日常运维中也不够友好。一个持续增长的巨大AOF文件在启动加载时耗时很长，而且无法利用操作系统层面的缓存优化，文件与进程之间的信息交互全靠Redis自己维护额外的状态。
multi-part AOF的文件组织结构
Redis 7.0引入multi-part AOF后，AOF持久化的存储单元不再是单个文件，而是一组文件的集合，具体分为三类：基础AOF文件、增量AOF文件和Manifest清单文件。基础AOF文件存放在一个名为appendonlydir的子目录中，由重写过程产生，保存的是某一时刻内存数据的完整快照形态的命令表示。增量AOF文件记录的是每次重写之后新产生的写命令，可以有一个或多个。
Manifest文件是这套机制的核心枢纽，它以文本格式记录了当前AOF体系由哪些文件组成、每个文件的大小、序列号以及各自的用途。Redis启动加载AOF时，不再按固定文件名去找数据，而是先读取Manifest，根据其中描述的文件列表依次加载基础文件和所有增量文件。这样做的好处是文件名可以自由命名，比如incrfilepart-1.aof、incrfilepart-2.aof，扩展性大大增强。
我们来看一个典型的目录结构：
appendonlydir/ ├── appendonly.aof.1.base.rdb # 基础文件，此处采用RDB格式 ├── appendonly.aof.1.incr.aof # 增量AOF文件 ├── appendonly.aof.2.incr.aof # 重写后会产生新的增量文件 └── appendonly.aof.manifest # 清单文件，描述上述文件的组织关系
Manifest文件的内容大致如下，可以直观看到文件清单：
file appendonly.aof.1.base.rdb seq 1 type b file appendonly.aof.1.incr.aof seq 1 type i file appendonly.aof.2.incr.aof seq 2 type i
其中type为b表示base基础文件，type为i表示incr增量文件，seq是序列号，Redis按照序列号顺序加载增量文件，保证命令回放的顺序正确。
重写流程的变化：不再需要AOF重写缓冲区
multi-part AOF带来的最大架构变化是重写流程的简化。由于文件被拆分为基础部分和增量部分，重写时子进程只需要生成新的基础文件，而重写期间的新写命令直接写入一个新的增量AOF文件即可。也就是说，旧版中同时维护旧AOF文件加重写缓冲区的双写模式被彻底取消了。
具体过程是：主进程fork出子进程，子进程开始生成新的基础AOF文件；与此同时主进程新开一个增量文件，后续所有写命令都追加到这个增量文件中。子进程完成后，主进程修改Manifest清单，把新的基础文件和新增量文件登记进去，并删除不再需要的旧文件。整个过程中主进程无需维护大块的重写缓冲区，内存压力显著降低，也避免了旧版重写失败可能导致崩溃的问题。
对于AOF文件格式的选择，Redis 7.0还支持基础文件采用RDB格式，通过配置项aof-use-rdb-preamble控制，默认开启。RDB格式的基础文件体积小、加载快，配合增量命令文件，整体恢复速度比纯命令格式的AOF快得多。这也是官方文档中提到的混合持久化在新架构下的自然延伸。
相关的重要配置项如下：
# 开启AOF appendonly yes # AOF文件所在目录，multi-part结构存放于此 appenddirname "appendonlydir" # 重写触发条件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 基础文件是否采用RDB格式 aof-use-rdb-preamble yes
升级注意事项与常见问题
从旧版本升级到Redis 7.0时，官方保留了旧AOF文件的兼容加载能力。如果启动时在数据目录发现旧的appendonly.aof文件，且不存在appendonlydir目录，Redis会自动把旧文件转换成multi-part结构，写入新的appendonlydir目录，这个过程是一次性的。建议在升级前做好数据备份，因为转换过程中如果中断，可能出现新旧两套AOF并存导致混淆的情况。
运维层面需要注意两点。第一，磁盘空间监控的对象要从单个文件改为整个appendonlydir目录，因为旧基础文件和新增量文件在重写完成、清单更新之前会短暂共存，磁盘峰值占用会比旧版略高。第二，备份策略要包含Manifest文件，只备份.aof文件而遗漏manifest会导致恢复时无法正确组织文件，出现数据加载失败的错误。
常见问题方面，如果启动时报错找不到基础文件或增量文件，通常是Manifest与目录内实际文件不一致造成的，比如手动删除了某个文件。此时应根据Manifest内容核对，或者以目录内实际文件重建清单。另一个容易困惑的点是incr开头的增量文件在重写后不会立即合并，它们会一直保留，直到下一次重写生成新基础文件时才清理旧的增量文件，这是设计使然而非异常。
总体来说，multi-part AOF是Redis 7.0在持久化子系统中一次非常务实的重构，它通过文件拆分和清单管理，消除了重写缓冲区的内存开销，降低了重写失败的风险，同时提升了启动加载的灵活性和速度。对于生产环境中大内存实例较多的团队，升级到7.0并采用新版AOF机制，是一个收益明确的改进。
Redis 7.0multi-part AOFAOF持久化修改时间：2026-09-15 01:09:34