Redis持久化机制中的 AOF机制简单介绍

[一、AOF 核心原理（一句话总结）](#一、AOF 核心原理（一句话总结）)

[二、AOF 的核心流程](#二、AOF 的核心流程)

[1. 开启 AOF（默认关闭）](#1. 开启 AOF（默认关闭）)

[2. 命令追加](#2. 命令追加)

[3. 同步策略（核心配置，平衡安全与性能）](#3. 同步策略（核心配置，平衡安全与性能）)

[4. AOF 重写（解决文件膨胀问题）](#4. AOF 重写（解决文件膨胀问题）)

[5. 数据恢复](#5. 数据恢复)

[三、AOF vs RDB](#三、AOF vs RDB)

[四、进阶：混合持久化（Redis 4.0+ 推荐）](#四、进阶：混合持久化（Redis 4.0+ 推荐）)

AOF（Append-Only File）是 Redis 第二种核心持久化机制，和 RDB 的 "快照式备份" 不同，它靠记录写命令日志实现数据持久化

Redis 执行所有写命令 （如 SET、DEL、HSET 等）时，会把命令以可读的文本格式追加到 AOF 文件末尾；Redis 重启时，重新执行 AOF 文件里的所有命令，就能还原内存数据。

就像你写作业时，把每一步解题步骤记在笔记本上，就算作业本丢了，照着步骤重新写一遍，就能还原最终答案。

需在 redis.conf 中配置：

复制代码

appendonly yes  # 开启 AOF（默认 no）
appendfilename "appendonly.aof"  # AOF 文件名，默认存在 Redis 安装目录

Redis 执行写命令后，先把命令写入内存缓冲区 （避免频繁刷盘），再按 "同步策略" 刷到磁盘的 AOF 文件。比如执行 SET user:balance 100，AOF 文件里会新增一行：

复制代码

*3
$3
SET
$12
user:balance
$3
100

（注：这是 Redis 的 "RESP 协议格式"，可读性虽不如纯文本，但 Redis 能识别，也可通过 redis-cli --pipe 解析）

AOF 关键是 "何时把缓冲区的命令刷到磁盘"，通过 appendfsync 配置，有 3 种选择：

配置值	含义	数据安全性	性能影响	适用场景
`always`	每次写命令都立即刷盘	最高（几乎不丢）	最差（频繁 I/O）	金融交易、对账等核心场景
`everysec`	每秒刷盘 1 次（默认）	较高（最多丢 1 秒）	平衡（推荐）	电商、社交等常规场景
`no`	仅把命令交给操作系统，由系统决定何时刷盘（通常 30 秒）	最低（可能丢大量）	最好	非核心数据、纯缓存场景

配置示例：

复制代码

appendfsync everysec  # 推荐的默认配置

为什么要重写 ：AOF 不断追加命令，文件会越来越大（比如反复修改 user:balance，AOF 会存所有修改命令），既占磁盘，重启恢复也慢。
重写原理 ：Redis fork 子进程，遍历当前内存数据，生成 "能还原数据的最简命令集"，替换旧的 AOF 文件。比如内存中 user:balance 最终值是 120，不管之前改了多少次，重写后 AOF 里只剩 SET user:balance 120。

触发方式 ：

自动：配置阈值（满足以下 2 个条件触发）：

复制代码

auto-aof-rewrite-min-size 64mb  # AOF 文件至少 64MB 才触发
auto-aof-rewrite-percentage 100 # 当前文件比上次重写后大 100%（翻倍）触发

把 appendonly.aof 放到 Redis 配置的 dir 目录下，启动 Redis，Redis 会自动读取 AOF 文件，按顺序执行所有命令，恢复数据。

开启 aof-use-rdb-preamble yes 后，AOF 文件开头是 RDB 格式的全量快照，后面是增量 AOF 命令：

AOF 核心是 "记命令日志"，通过同步策略控制数据安全性，通过重写解决文件膨胀，适合对数据丢失容忍度低的场景；生产环境通常建议开启 AOF + 混合持久化，搭配 RDB 做定期备份，既保证数据安全，又兼顾恢复效率。