Redis持久化方案之AOF

一 概述

AOF(Append-Only-File)持久化，保持写状态，通过保持Redis的写状态来记录数据库的增量指令，RDB相当于备份数据库状态，而AOF是备份数据库接收到的指令，所有写入AOF中的命令都是以Redis的协议格式来保存，在AOF的持久化文件中，数据库会记录下所有变更数据库的命令，除了指定数据库的查询命令，其他的命令都是来自客户端请求，这些命令会以追加即（append）的形式保存在文件中。

二 AOF配置与解析

appendonly no //由Redis的配置可知，AOF持久化方式默认是关闭的

appendonly yes //开启AOF持久化方式的命令

appendfilename "appendonly.aof" //配置文件中指定的文件名

AOF文件内容写入方式的配置

appendfsync always //一旦缓存区的内容发生变化，会及时的将缓存区的内容写入持久化文件中

appendfsync everysec //默认方式，每隔一秒，将缓存区变化的内容写入持久化文件中，此处基于性能和安全性的考虑

appendfsync no //指AOF持久化文件的写入操作由操作系统来决定，为了效率，操作系统会等到缓存区被填满才将缓存区内的内容持久化到磁盘中

AOF持久化方式为纯追加的持久化方式保存增加的指令，所以遇到突然断电的情况时，也会尽可能的去保存追加的命令。

当然，由于追加方式，AOF操作会使得文件越来越大，如我们递归一个数据，他会将递归的过程全部保存，往往我们仅仅需要最后的递归结果，所以可以通过日志重写解决AOF文件大小不断增加的问题。

日志重写的原理为：Redis会通过fork命令来创建一个子进程，子进程会将新AOF保存到一个临时文件中，新的AOF中内容就是将当前内存数据生成对应命令，并不需要分析旧的AOF文件，或者命令合并，则主进程会将新的变动同时写如缓存和旧的AOF文件中，这样即使重写失败，也可以保证数据的安全，当子进程完成AOF的重写之后主进程会获得一个信号，然后将缓存中的指令（同一操作的最后指令）追加到子进程生成的那个新的AOF文件中，最后用新的AOF文件替换旧的AOF文件。至此就完成了一次日志重写解决AOF文件过大问题。

三 RDB与AOF并存时Redis的数据恢复

当我们的服务器系统中同时存在RDB文件与AOF文件的时，我们应该如何进行这些文件的加载以及根据这些文件的加载内容实现数据的恢复呢？

如图所示，当我们需要从上述文件中恢复数据库数据，其实只需要重启Redis服务集合，整个启动过程如上图所示。在Redis实例重启时，会使用BGSAVE持久化文件构建内容，再使用AOF重放近期的操作指令，来实现恢复重启的状态。

Redis4.0之后提供了RDB-AOF混合持久化方式，并且作为默认方式。我们知道RDB文件本质上时内存数据的全量快照，它保存创建RDB时间点的全量数据，具有创建文件小，数据创建恢复快的优点，但是由于快照的特性无法保存创建RDB文件后的增量数据。而AOF文件本质上是一份执行日志，它保存所有对Redis进行更改的指令，即增量数据也会随着这些指令写入AOF文件，其保存方式为根据appendfsync+某一参数来执行，AOF一般体积较大，从AOF文件中恢复数据的时候，需要进行日志回放，即重复AOF文件中所有指令的执行过程，所以会耗时较长。随着Redis服务运行，AOF文件会不断的扩大，我们可以调用AOF REWIRTE机制来避免避免磁盘空间被撑满。

AOF重写机制：AOF重写机制其实也是写一份全量数据到AOF文件中，然后再增加增量，全量数据是以Redis命令的格式写入，所以如果先通过RDB方式写入全量数据，然后通过AOF方式写入增量，从而提高重写和恢复速度，也可以减少文件大小，同时保证数据的完整性，能够结合RDB和AOF的优点，再RDB-AOF混合持久化方式下，子进程会通过管道从父进程读取增量数据，并缓存下来，以RDB方式保存全量数据时也会从管道读取数据，这样不会造成管道的堵塞，此时AOF的前半段是RDB方式获取的全量数据，后半段是Redis格式的增量数据，RDB-AOf混合持久化方式是比较推荐的一种Redis持久化方式，通过BGSAVE做镜像全量持久化，AOF做增量持久化。BGSAVE操作会耗费一段时间，在等待的时候，会存在数据丢失，所以配合AOF使用来解决这个问题。