开启aof-use-rdb-preamble yes后，Redis 7.0+ AOF重写仅生成单个文件（如appendonly.aof），废弃多文件结构；其本质是RDB快照+增量命令的线性日志，无法像LevelDB分片，需聚焦IO/CPU优化而非拆分文件。
Redis 7.0+ 的 aof-use-rdb-preamble 怎么影响 AOF 文件数量
开启 aof-use-rdb-preamble yes 后，Redis 不再生成纯文本 AOF，而是用 RDB 格式打底 + 增量命令追加——结果是：**AOF 重写时只产生单个文件**，无论配置多少个 AOF 文件，实际落地仍是 appendonly.aof（或你配的 appendfilename）。多文件结构在 Redis 7.0+ 已被弃用，所谓“AOF 多文件”只是旧文档残留概念。
常见错误现象：CONFIG GET aof-file 返回空、redis-cli --rdb 解析失败、重写后磁盘空间未按预期分片。
- Redis 6.2 引入的
aof-rewrite-incremental-fsync仅控制 fsync 频率，不拆文件 -
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size触发的仍是单文件重写 - 若手动用
BGREWRITEAOF，且未开启aof-use-rdb-preamble，仍为单文件；但该模式已不推荐，且 7.0 默认开启
为什么不能像 LevelDB 那样手动切分 AOF 文件
Redis 的 AOF 本质是**线性日志流**，不是可随机访问的 segment。它依赖完整命令序列重建状态，没有 WAL 分片元数据、无 checkpoint offset 管理机制。强行拆成多个 appendonly.001.aof、appendonly.002.aof 会导致：
- 启动时无法判断加载顺序，
redis-server只认配置的appendfilename单文件 -
redis-check-aof --fix无法跨文件校验完整性 - 主从复制中，
REPLCONF ACK基于全局偏移量，多文件会破坏偏移连续性 - 即使改源码硬塞多文件逻辑，
fork()重写过程仍需全量读取内存快照 → 实际 I/O 并未减少
想降低 AOF 重写压力，真正有效的替代方案
与其纠结“怎么分文件”，不如聚焦 IO 和 CPU 瓶颈本身。Redis 官方路径很明确：
- 用
aof-use-rdb-preamble yes（默认），让重写走 RDB 快照 + 尾部增量，大幅缩短阻塞时间 - 调大
aof-rewrite-incremental-fsync（默认 4MB），减少重写期间 fsync 次数 - 关闭
no-appendfsync-on-rewrite yes，避免重写时积压大量待写命令导致 buffer 溢出 - 若写入量极大，考虑把 AOF 文件放在更快的存储（如 NVMe），而非靠拆文件“假装并行”
注意：appendonly.aof 文件大小受 auto-aof-rewrite-min-size 控制，但重写后不会自动 truncate 原始文件——得靠 CONFIG SET appendonly no && CONFIG SET appendonly yes 手动轮转，或等下一次重写自然覆盖。
升级到 Redis 7.0+ 后检查 AOF 行为的关键命令
别信配置文件注释，直接看运行时表现：
-
CONFIG GET aof-use-rdb-preamble→ 必须返回yes，否则你还在用旧模式 -
INFO persistence→ 查看aof_enabled、aof_rewrite_in_progress、aof_current_size，确认没卡在重写中 -
redis-cli --rdb /var/lib/redis/appendonly.aof | head -n 5→ 若输出含REDIS0011或类似 RDB 魔数，说明 preamble 已生效 - 观察
ps aux | grep redis中是否有长期存在的redis-aof-rewrite进程 —— 有则说明重写卡住，大概率是 fork 失败或磁盘满
多文件 AOF 是个过时的误解。真正要盯紧的，是重写是否完成、RDB preamble 是否启用、以及磁盘 I/O 是否成为瓶颈。其他都是障眼法。
