AOF 开启与文件布局是什么
AOF 以追加方式记录每条写命令。appendonly yes 即开启；Redis 7.0 起 AOF 不再是单个 appendonly.aof 文件，而是 appendonlydir 目录下的 manifest、base 与 incr 三部分：base 是某时刻的全量数据，incr 是其后的增量命令，manifest 记录它们的关系。动态开启时会 fork 一次并生成 base 文件，大实例要安排在低峰。
基本信息
| 开关 | appendonly yes / no，动态修改会触发重写 |
|---|---|
| 文件名 | appendfilename 前缀，默认 appendonly.aof |
| 目录名 | appenddirname，7.0+ 默认 appendonlydir |
| 刷盘策略 | appendfsync always / everysec / no |
| 重写控制 | auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size |
典型使用场景
- 数据安全底线：把丢失窗口从分钟级压到约一秒
- 动态开启：先在低峰执行并用 INFO 跟踪重写进度
- 手动重写：BGREWRITEAOF 压缩文件体积、缩短恢复时间
- 备份：整个 appendonlydir 目录一起归档
- 排错：检查最近一次写入与重写是否成功
- 与 RDB 组合：AOF 保精度、RDB 保冷备与快速恢复
- 上线前评估：先在测试实例演练一遍，记录重写耗时与内存峰值
开启与核对
开启与核对
CONFIG SET appendonly yes # 动态开启，会触发一次重写
CONFIG GET appenddirname # 7.0+ 的 AOF 目录名
INFO persistence | grep aof_enabled # 1 表示已开启
INFO persistence | grep aof_rewrite_in_progress # 1 表示正在重写
INFO persistence | grep -E 'aof_last_write_status|aof_last_bgrewrite_status' # ok 为正常
BGREWRITEAOF # 手动重写，压缩体积
ls -lh /var/lib/redis/appendonlydir # 7.0+ 文件布局：manifest 加 base 加 incr
# CONFIG REWRITE # 把开关写回配置文件，避免重启失效appendfsync 对照
| 取值 | 行为 | 丢失窗口 |
|---|---|---|
| always | 每次写命令都刷盘 | 几乎不丢，但吞吐显著下降 |
| everysec | 每秒刷一次盘 | 最多约 1 秒，生产常用 |
| no | 交给操作系统决定 | 不可控，可能丢失更多 |
动态开启 AOF 会 fork 重写一次（已有数据转为 base）；大实例上安排在低峰，并用 INFO 跟踪 aof_rewrite_in_progress。
Redis 7.0 起备份 AOF 必须整个 appendonlydir 目录一起拷贝：只拷 base 或只拷 incr 文件都无法独立恢复，manifest 缺失时实例甚至无法加载。
开启 AOF 后要同步核对重写阈值：auto-aof-rewrite-percentage 与 min-size 过小会频繁重写、抢占 IO，过大则文件长期膨胀、重启恢复时间被拉长；通常按经验值观察一轮再微调。
同时开启 RDB 与 AOF 时，实例重启默认优先用 AOF 恢复（丢失窗口更小）；这点也决定了备份时必须把 AOF 相关文件一起归档，否则恢复时仍会退回 RDB 的数据点。