AOF持久化

AOF(Append Only File)以日志形式记录Redis的所有写命令，恢复时重新执行命令还原数据。

AOF原理

工作流程

Bash

AOF流程：
1. 客户端发送写命令
2. Redis执行命令
3. 命令写入AOF缓冲区
4. 根据策略同步到磁盘
5. AOF文件追加写入

命令记录格式

Bash

AOF文件是文本格式，记录Redis协议命令：
*3
$3
SET
$5
mykey
$7
myvalue

# 以上表示：SET mykey myvalue

恢复流程

Bash

数据恢复：
1. Redis启动读取AOF文件
2. 创建伪客户端
3. 逐条执行写命令
4. 恢复内存数据

AOF配置

开启AOF

Bash

# redis.conf配置
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# AOF文件目录（与RDB共享）
dir /var/lib/redis

同步策略

Bash

# 三种同步策略
appendfsync always    # 每次写入都同步
appendfsync everysec  # 每秒同步（推荐）
appendfsync no        # 由系统决定

# 默认推荐everysec
appendfsync everysec

同步策略对比

策略	说明	性能	数据安全
always	每次写入同步	最差	最高（最多丢失1条）
everysec	每秒同步	中等	较高（最多丢失1秒）
no	系统决定	最佳	最低（可能丢失30秒）

everysec是推荐配置，平衡性能和数据安全。

AOF重写

重写必要性

Bash

问题：
- AOF文件持续增长
- 包含大量冗余命令
- 如多次SET同一key
- 文件越来越大

解决：
- AOF重写压缩文件
- 只保留最终数据状态
- 减少文件体积

重写原理

Bash

AOF重写流程：
1. Redis fork子进程
2. 子进程遍历内存生成新AOF
3. 主进程继续记录命令到旧AOF和缓冲区
4. 子进程完成后，主进程追加缓冲区命令
5. 新AOF替换旧AOF

重写触发条件

Bash

# 自动触发条件
auto-aof-rewrite-percentage 100  # 文件比上次重写后增长100%
auto-aof-rewrite-min-size 64mb   # 文件最小64MB才触发

# 手动触发
BGREWRITEAOF

重写过程

Bash

重写前：AOF文件100MB
SET key1 "value1"
SET key1 "value2"
SET key1 "value3"
...

重写后：只保留最终状态
SET key1 "value3"

重写配置

Bash

# 重写触发百分比
auto-aof-rewrite-percentage 100

# 重写触发最小大小
auto-aof-rewrite-min-size 64mb

# 重写时是否禁用fsync
no-appendfsync-on-rewrite no

# 设置yes可避免重写时fsync阻塞
# 但可能丢失数据

AOF文件结构

命令格式

Bash

Redis协议格式：
*<参数数量>
$<参数长度>
<参数内容>
...

示例：SET mykey myvalue
*3
$3
SET
$5
mykey
$7
myvalue

查看AOF内容

Bash

# 直接查看文本
cat appendonly.aof

# 查看文件大小
ls -lh appendonly.aof

AOF优点

优点列表

Bash

1. 数据安全
   - everysec最多丢失1秒数据
   - always最多丢失1条命令

2. 可读性强
   - 文本格式，便于查看
   - 可手动修复错误命令

3. 支持重写
   - 自动压缩文件
   - 减少磁盘占用

4. 实时持久化
   - 命令即时记录
   - 非定时快照

AOF缺点

缺点列表

Bash

1. 文件较大
   - 比RDB文件大
   - 包含所有命令记录

2. 恢复较慢
   - 需执行所有命令
   - 比RDB加载慢很多

3. 性能略低
   - 额外的写入开销
   - fsync消耗CPU

4. 可能阻塞
   - 重写时fsync可能阻塞
   - 大量写入时磁盘压力大

性能对比

text

AOF恢复：GB级数据几分钟到几十分钟
RDB恢复：GB级数据几秒到几十秒

AOF文件：比RDB文件大2-5倍（未重写时）

AOF恢复

恢复流程

text

# 1. 将AOF文件放到数据目录
cp appendonly.aof /var/lib/redis/

# 2. 启动Redis自动加载
redis-server

文件修复

text

# AOF文件损坏时可修复
redis-check-aof --fix appendonly.aof

# 修复时会截断损坏部分
# 可能丢失部分数据

查看修复结果

text

# 检查AOF文件
redis-check-aof appendonly.aof

# 输出：
# AOF analyzed: ...
# AOF is valid

AOF与RDB共存

加载优先级

text

Redis启动加载顺序：
1. AOF开启 → 加载AOF
2. AOF关闭 → 加载RDB
3. 都关闭 → 空数据库启动

同时开启配置

text

# 同时开启AOF和RDB
appendonly yes
save 900 1

# 启动时优先加载AOF
# AOF数据更完整

建议配置

text

# 推荐配置（Redis 4.0+）
appendonly yes
appendfsync everysec

# 开启混合持久化
aof-use-rdb-preamble yes

# 自动重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

性能优化

fsync优化

text

# 重写时禁用fsync（可能丢失数据）
no-appendfsync-on-rewrite yes

# 或保持默认（重写时可能阻塞）
no-appendfsync-on-rewrite no

重写优化

text

# 调整重写触发条件
auto-aof-rewrite-percentage 50  # 更频繁重写
auto-aof-rewrite-min-size 32mb  # 更早触发

# 避免AOF文件过大

系统优化

text

# 磁盘性能
# 使用SSD提高写入性能
# 确保磁盘空间充足

# 内核参数
sysctl -w vm.dirty_ratio=10

监控指标

INFO命令查看

text

INFO persistence

# 关键指标
aof_enabled: AOF是否开启(1/0)
aof_current_size: 当前AOF文件大小
aof_base_size: 上次重写时的大小
aof_pending_rewrite: 是否有待执行的重写
aof_rewrite_in_progress: 是否正在重写
aof_last_rewrite_time_sec: 上次重写耗时
aof_last_bgrewrite_status: 上次重写状态(ok/err)

监控告警

text

- AOF文件过大告警（>指定大小）
- 重写失败告警
- 重写耗时过长告警（>60秒）

要点总结

AOF记录所有写命令，以日志形式持久化
appendfsync everysec推荐，最多丢失1秒数据
AOF重写压缩文件，只保留最终数据状态
auto-aof-rewrite-percentage 100触发自动重写
优点：数据安全、可读性强、实时持久化
缺点：文件较大、恢复较慢、性能略低
AOF损坏可用redis-check-aof --fix修复
启动时AOF优先级高于RDB
Redis 4.0+开启混合持久化，结合两者优点
监控AOF大小和重写状态，异常告警

📝 发现内容有误？点击此处直接编辑