当前位置：首页 > news >正文

Redis的持久化-AOF

news 来源：原创 2025/8/17 22:31:23

1.AOF

AOF（Append Only File）持久化：以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。理解掌握好AOF持久化机制对我们兼顾数据安全和性能非常有帮助。

有人就要问了：引入AOF之后，又要写内存，又要写硬盘，还能和之前一样快吗？

实际上影响是不大的，并没有影响到Redis处理请求的速度，原因在于： 1.AOF机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存缓冲区，积累一定数量的数据后，在统一写入硬盘（这样大大降低了些硬盘的次数）

2.硬盘上读写数据，顺序读写的速度是比较快的（当相比于写内存还是要慢很多），随机访问则是比较慢的。AOF每次把新的操作写入到原有文件的末尾，属于顺序读写

2.AOF的使用

2.1 使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置（默认是appendonly.aof）设置。保存目录同RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append），文件同步（sync），文件重写（rewrite），重启加载（load）

2.2 AOF工作流程

1.所有写入命令会追加到aof_buf(缓冲区)中

2.AOF缓冲区根据对应的策略向硬盘做同步操作

3.随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的

4.当Redis服务器启动时，可以加载AOF文件数据恢复

2.3 命令写入

AOF命令写入的内容直接是文本协议格式，在AOF缓冲区会追加文本内容

Redis选择文本协议的可能原因：文本协议具有较好的兼容性，实现简单，具备可读性

AOF过程中为什么需要aof_buf这个缓冲区？ Redis使用单线程响应命令，如果每次写AOF文件都直接同步硬盘，性能从内存的读写编程IO读写，必然会下降。先写入缓冲区可以有效减少IO次数，同时，Redis还可以提供多种缓冲区同步策略，让用户根据自己的需求做出合理的平衡

2.4 文件同步

Redis提供了多种AOF缓冲区同步策略，由参数appendfsync控制。

AOF缓冲区同步文件策略

可配置值	说明
always	命令写入aof_buf后调用fsync同步，完成后返回
everysec(默认)	命令写入aof_buf后只执行write操作，不进行fsync。每秒由同步线程进行fsync
no	命令写入aof_buf后只执行write操作，由OS控制fsync频率

系统调用write和fsync说明：

write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提供硬盘IO性能。write操作在写入系统缓冲区立即返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页控件写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区数据将丢失

fsync针对单个文件操作，做强制硬盘同步，fsync将阻塞直到数据写入到硬盘中

1.配置为always时，每次写入都要同步AOF文件，性能很差，在一般的SATA硬盘上，只能支持大约几百TPS写入。除非是非常重要的数据，否则不建议配置

2.配置为no时，由于操作系统不同策略不可控，性能虽然提高了，但是数据丢失风险大增，除非数据重要程度很低，一般不建议配置

3.配置为everysec（默认配置）时，兼顾了数据安全和性能。理论上最多丢失1秒的数据

2.5 重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件

重写后的AOF文件为什么会变小？ 这是因为AOF文件中有一些内容是冗余的，Redis启动过程中读取AOF文件的内容，记录了中间的过程，实际上Redis在重新启动时只关注最终结果。

冗余的内容： 1.进程内已经超时的数据不再写入文件 2.旧的AOF中的无效命令，例如del，hdel，srem等重写后将会删除，只需要保留数据的最终版本 3.多条写操作合并为一条，例如lpush list a，lpush list b，lpush list c可以合并为lpush list a b c 较小的AOF文件一方面降低了硬盘空间占用，一方面可以提升启动Redis时数据恢复的速度

AOF重写过程可以手动触发也可以自动触发：

手动触发：调用bgrewriteaof命令

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。 auto-aof-rewrite-min-size：表示触发重写时AOF的最小文件大小，默认为64MB auto-aof-rewrite-percentage：代表当前AOF占用大小相比较上次重写时增加的比例

AOF重写的流程

1.执行AOF重写请求（bgrewriteaof）。如果当前进程正在执行AOF重写，请求不执行，直接返回。如果当前进程正在执行bgsave操作（生成RDB快照），重写命令延迟到bgsave完成之后再执行

2.父进程执行fork创建子进程

3.重写 3.1）主进程fork之后，继续响应其他命令。所有修改操作写入AOF缓冲区并根据appendfsync策略同步到硬盘上，保证旧AOF文件机制正确 3.2）子进程只有fork之前的所有内存信息，父进程中需要将fork之后这段时间的修改操作写入AOF的重写缓冲区中

4.子进程根据内存快照，将命令合并到新的AOF文件中

5.子进程完成重写操作 5.1）新文件写入后，子进程发送信号通知父进程 5.2）父进程把AOF重写缓冲区临时保存的命令追加到新的AOF文件中 5.3）用新的AOF文件代替旧AOF文件

2.6 重启时数据恢复

当Redis启动时，会根据RDB和AOF文件的内容，进行数据恢复

Redis根据持久化文件进行数据恢复

当Redis同时存在AOF文件和RDB快照，此时以AOF为主，RDB直接被忽略（这是因为AOF中包含数据比RDB更全）

3.Redis持久化回顾

1.Redis提供了两种持久化方案：RDB和AOF

2.RDB视为内存的快照，产生的内容更为紧凑，占用空间较小，回复速度更快。但产生RDB的开销较大，不适合实时持久化，一般用于冷备和主从复制

3.AOF视为对修改命令的保存，在恢复时需要重放命令。并且有重写机制来定期压缩AOF文件

4.RDB和AOF都使用fork创建子进程，利用Linux子进程拥有父进程内存快照的特点进行持久化，尽可能不影响主进程继续处理后续命令