一文讲透Redis AOF持久化机制(超详细!!)

AOF(append only file) 简介

Redis 的 AOF（Append-Only File）持久化机制 是一种通过记录所有写操作命令来实现数据持久化的方式。它通过追加日志文件的形式保存数据变更历史，在 Redis 重启时重新执行这些命令来恢复数据。

1. 原理

• 以日志形式记录每一个写操作, 将 Redis 执行过的所有 写指令 记录下来, 只许追加文件但不可以改写文件, Redis 服务启动时会读取该文件重新构建数据。

2. 开启方法

默认情况下 AOF 持久化机制 是关闭的, 需对 redis.conf 配置文件进行修改。

# 将 appendonly 选项改为 yes
appendonly yes

3. 工作流程

1. 客户端向 Redis 服务发送请求
2. Redis 将接收的请求放入 AOF 缓冲区进行保存, 等待命令达到一定数量后, 统一写入, 避免频繁进行 I/O操作 产生性能损耗。
3. AOF 缓冲区根据 always , everysec, no 三种不同的同步策略写入命令
4. 根据规则进行 AOF重写， 对命令进行压缩, 以达到 AOF 文件压缩的目的
5. Redis 服务重启, 读取 AOF 文件, 恢复数据

4. 同步策略

在了解 同步策略前, 需了解同步策略中涉及的两个系统调用

write:

• 作用:

  将数据从用户空间缓冲区复制到内核的 页面缓存 (Page Cache)

• 特点:

  异步操作, 不保证数据持久化到磁盘

fsync:

• 作用:

  强制将内核页面缓存中的数据写入物理磁盘中

• 特点:

  同步阻塞操作, 需等待磁盘确认写入完成

always:

定义:

每个写命令执行后立即写入并同步到磁盘。数据最安全，但性能消耗最高。

工作机制：

• 命令追加: 主线程将写命令追加到内存缓冲区aof_buf
• 写入内核缓冲区: 调用 write 系统调用将 aof_buf 内容写入内核缓冲区
• 立即调用 fsync , 阻塞主线程直到数据完全写入磁盘

特点:

• 数据安全性高, 故障时最多丢失一条为完成写入的命令
• 性能最低: 频繁的 fsync 导致高磁盘 I/O延迟

适用场景:

对数据一致性要求极高的场景, 如金融交易, 需接收性能损失

everysec(默认策略):

定义:

每秒调用一次 fsync , 由后台线程异步执行。

工作机制:

• 主线程将写命令追加到 aof_buf, 并通过 write 写入内核缓冲区。
• 后台线程每秒触发一次 fsync, 将内核缓冲区的数据刷入磁盘
• 主线程仅在缓冲区满或后台线程未及时同步时短暂阻塞

特点:

• 性能和安全得到平衡, 故障时最多丢失 1 秒内的数据
• 使用异步处理, 同步操作由后台线程完成，主线程基本无阻塞。

使用场景:

常规业务系统

no:

定义:

仅将数据写入内核缓冲区，依赖操作系统自动同步到磁盘。

工作机制:

• 主线程将写命令追加到 aof_buf，调用 write 写入内核缓冲区。
• Redis 不主动触发 fsync，由操作系统决定同步时机（通常间隔 30 秒）。

特点:

• 性能最高, 吞吐量最大, 无fsync调用
• 数据安全性无法保障, 故障可能丢失大量数据

适用场景:

不在乎数据安全的非关键场景。

修改策略方法:

编辑 redis.conf 文件, 找到 appendfsync 选项, 将默认的 everysec 策略注释, 取消需要使用的策略的注释:

# appendfsync always
appendfsync everysec
# appendfsync no

5. 修改 .aof 文件的保存路径和保存名称

编辑 redis.conf 配置文件, 修改 appenddirname 选项和 appendfilename 选项

appendfilename "appendonly-6379"

appenddirname "appendOnlyFileDir"

修改完成后, 就会将 .aof 文件 dir 选项的指定持久化目录中的 appendOnlyFile

目录下，并自动命名为: appendonly-6379.aof

注: appenddirname 配置相对路径, 与 dir 选项的路径下

6. MP-AOF 机制

在 redis v7.* 之前, AOF 使用单个文件机制, 重写时需生成完整新文件，导致磁盘空间占用高、重写期间性能抖动。

而在 redis v7.0 后, 引入了 MP-AOF 机制, 通过清单文件（Manifest）管理多个 AOF 片段，避免因重写失败或崩溃导致数据丢失。并且支持增量式数据管理，便于备份、迁移和恢复。

6.1 核心机制：

1. 文件结构拆分：

   MP-AOF 将数据分为三类文件：

   • Base AOF（基础文件）：
     初始全量数据的快照（类似 RDB），格式为 ​RDB-AOF 混合文件​（默认开启），文件后缀为 .base.rdb。
   • Incremental AOF（增量文件）：
     记录基础文件生成后的增量写操作，后缀为 .incr.aof。
   • Manifest 文件：如 appendonly.aof.manifest，记录所有 AOF 文件的元数据（如文件名、序列号、类型），用于指导 Redis 启动时的数据恢复顺序。

2. 清单文件：

   • 作用：记录所有 AOF 文件的元信息（如文件顺序、类型、版本），确保重启时正确加载数据。
   • 文件格式：JSON 格式，默认文件名为 appendonly.aof.manifest。
   • 更新规则：每次AOF重写或增量文件切换时更新清单文件。

3. 重写流程优化：

   • 增量重写：MP-AOF 不再生成完整新文件，而是将增量数据追加到现有文件，减少磁盘 I/O 压力。
   • 原子性切换：重写完成后，通过更新清单文件实现新旧文件原子替换，避免数据不一致。

MP-AOF 大多数选项都默认开启，此处只针对重写策略调优进行讲解, 若有需求可查看[redis官网](Redis persistence | Docs)

# 触发条件
auto-aof-rewrite-percentage 100   # 当前 AOF 文件大小超过上次重写大小的 100%
auto-aof-rewrite-min-size 64mb    # 最小重写文件大小

# 后台重写子进程限制（避免 OOM）
aof-rewrite-incremental-fsync yes # 增量同步数据到磁盘

6.2使用命令对 MP-AOF 进行监控和维护:

# 查看 MP-AOF 状态
127.0.0.1:6379> info persistence

# 手动触发重写
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started # 出现这行代码表示成功

# 检查清单文件内容
[root@redis-master ~]# cat /var/lib/redis/dumpfiles/appendOnlyFileDir/appendonly-6379.aof.manifest
file appendonly-6379.aof.1.base.rdb seq 1 type b
file appendonly-6379.aof.1.incr.aof seq 1 type i

7. 数据恢复

7.1. 优先级

• 优先加载 AOF：若同时启用了 RDB 和 AOF，Redis 会优先选择 AOF 文件进行恢复，因为 AOF 记录了更完整的数据（包含最后一次快照后的所有写操作）
• 回退机制：若 AOF 文件损坏或不存在，Redis 会尝试加载 RDB 文件

7.2 过程

• 逐条执行命令：Redis 将 AOF 文件中的命令按写入顺序重新执行，例如 SET、INCR 等操作会被依次应用到内存数据库
• 混合持久化优化（Redis 7.0+）：若启用了 aof-use-rdb-preamble，AOF 文件头部会包含 RDB 格式的快照数据，后续追加增量命令。恢复时先加载 RDB 快照，再重放增量命令，显著提升恢复速度

7.3 修复 .aof 文件

使用 redis-check-aof 修复工具可针对 .aof文件进行修复

示例:

[root@redis-master ~]# redis-check-aof --fix /var/lib/redis/dumpfiles/appendOnlyFileDir/appendonly-6379.1.incr.aof

放增量命令，显著提升恢复速度

7.3 修复 .aof 文件

使用 redis-check-aof 修复工具可针对 .aof文件进行修复

示例:

[root@redis-master ~]# redis-check-aof --fix /var/lib/redis/dumpfiles/appendOnlyFileDir/appendonly-6379.1.incr.aof