Redis AOF持久化详解：配置策略、重写机制与RDB对比

Redis AOF通过记录写命令实现数据持久化，但默认未开启且文件易膨胀。本文从配置开启、写入与重写机制、自动触发策略到fsync同步选项逐步拆解，并对比RDB，帮助你在生产环境中做出兼顾安全与性能的决策。

开启AOF持久化

AOF（Append Only File）采用追加模式记录所有修改内存的命令，默认存储文件为appendonly.aof。该机制默认关闭，需修改配置文件并重启服务生效。

Windows系统配置

#修改配置文件，把no改为 yes
appendonly yes
#确定存储文件名是否正确
appendfilename "appendonly.aof"
#重启服务器
redis-server --service-stop
redis-server --service-start

Linux系统配置

#修改配置文件：
vim /etc/redis/redis.conf
appendonly yes # 把 no 改为 yes
#确定存储文件名是否正确
appendfilename "appendonly.aof"
#重启服务：
sudo /etc/init.d/redis-server restart

建议在Linux环境下操作与测试，以便更直观地观察AOF的IO行为与性能表现。

AOF写入与重写机制

AOF的核心是“命令重演”：服务器将执行过的修改命令写入appendonly.aof，重启时重新执行该文件即可恢复数据。

写入机制与缓冲区

客户端修改命令通过校验后，Redis会先将其追加到内存缓冲区（buffer），而非直接落盘。当缓冲区满足条件时，才会将内容写入磁盘。这种设计减少了频繁IO带来的性能损耗，但在宕机时，缓冲区未刷盘的数据仍可能丢失。

重写机制与文件瘦身

长期运行后，AOF文件会不断膨胀，导致恢复耗时过长。Redis提供BGREWRITEAOF命令进行重写：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

重写生成的新文件具备以下特征：

• 数据与原文件完全一致；
• 使用更少的命令表达相同状态，体积显著缩小；
• 重写过程不阻塞服务器，可正常处理客户端请求。

重写前后的命令对比如下：

可见，重写后的文件通过合并冗余操作，大幅简化了命令序列。

自动触发AOF重写

为避免手动维护，Redis提供自动重写策略。修改配置文件即可启用：

#默认配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。

当AOF文件体积达到auto-aof-rewrite-min-size阈值，且较上次重写后增长比例达到auto-aof-rewrite-percentage（默认100%，即翻倍）时，系统自动执行重写。若将百分比设为0，则关闭自动重写。

AOF同步策略与性能权衡

缓冲区数据何时刷盘决定了宕机时的数据丢失范围。Redis通过appendfsync参数提供三种策略：

图1：AOF策略配置

• Always：每执行一条写命令即调用fsync刷盘。数据最安全，但磁盘IO频繁，性能显著下降。
• Everysec（默认）：每秒调用一次fsync。最多丢失1秒数据，兼顾性能与安全，生产环境首选。
• No：不主动调用fsync，由操作系统决定刷盘时机。丢失数据量不确定，安全性差，不建议使用。

Linux系统的fsync()会将内核缓存刷入硬盘，属于较慢的磁盘IO操作。Always策略会严重拖慢Redis性能；Everysec在保持高性能的同时将丢失窗口控制在1秒内；No策略不确定性高，应避免在生产中使用。

AOF与RDB持久化对比

若同时存在dump.rdb与appendonly.aof，Redis启动时会优先使用AOF恢复数据，以最大程度保障数据完整性。实际部署中，可根据业务对RPO与性能的要求，选择单一策略或混合使用。