AOF持久化(保存的是操作redis命令)

前言

AOF也就是：append only file，上一篇文章学习了rdb快照持久化保存的是redis数据，aof持久化是保存的是操作redis的命令。

 

AOF持久化的原理

理论上我们只需要保存修改redis的命令（也就是写命令）就能根据这些命令恢复我们的内存数据。AOF也就是使用这个原来备份和恢复redis。

如图：

AOF配置

为了打开 AOF 持久化的功能，我们只需要将 redis.conf 配置文件中的appendonly配置选项设置为yes即可。涉及 AOF 持久化的几个常用配置如下所示:

appendonly yes appendfilename "appendonly.aof" appendfsync everysec

• appendonly：是否打开 AOF 持久化功能
• appendfilename：AOF 文件名称
• appendfsync：同步频率，可选配置如表1所示

 

表 1：appendfsync 选项及同步频率

选项 同步频率

always 每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能

everysec 每秒执行一次同步，显式地将多个写命令同步到硬盘

no 让操作系统来决定应该何时进行同步

aof持久化配置文件例子：

appendonly yes appendfilename "redis-63791.aof" appendfsync always port 63791 dir /diska/redis/ daemonize yes logfile /data/logs/redis/redis_63791.log pidfile /data/logs/redis/redis_63791.pid   # 配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写 auto-aof-rewrite-percentage 50 # 配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时，才会进行 AOF 重写 auto-aof-rewrite-min-size 10M

 

AOF 文件生成过程

AOF 文件的生成过程具体包括命令追加，文件写入，文件同步三个步骤。

Redis 打开 AOF 持久化功能后，Redis 在执行完一个写命令后，都会将执行的写命令追回到 Redis 内部的缓冲区的末尾。这个过程是命令的追加过程。

接下来，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程。只有经过文件同步过程，AOF 文件才在硬盘中真正保存了 Redis 的写命令。appendfsync 配置选项正是用来配置将写命令同步到文件的频率的，各个选项的值的含义如表 1 所示。

AOF文件

appendonly.aof以 Redis 协议格式 RESP 来保存写命令。由于 RESP 协议中包含了换行符，所以上面展示的 AOF 文件时遇到换行符时进行了换行。在 AOF 文件里面，除了用于指定数据库的 SELECT 命令是自动添加的之外，其他都是我们通过客户端发送的命令。

appendonly.aof保存的命令会在 Redis 下次重启时使用来还原 Redis 数据库。

 

AOF文件重写和压缩

aof持久化会把redis所有的写命令都保存到aof文件，使得aof文件越来越大，大大占用磁盘使用空间，也给还原redis数据很大时间。

那么怎么解决？aof是记录redis执行的写命令也就是一些重复执行的写命令都会记录到aof文件内，所以所删除重复的写入命令可以适当的缩小aof文件大小。redis提供了bgrewriteaof命令可以实现：bgrewriteaof命令和bgsave命令原理差不多，执行后都会fork一个子进程进行重写操作：

如：

执行一次 set a b后，查看aof文件大小： -rw-r--r-- 1 root root 50 2月 21 23:11 redis-63791.aof 在执行多次set a b，在查看aof文件大小： -rw-r--r-- 1 root root 586 2月 21 23:22 redis-63791.aof 可以看到aof文件比原来大10倍 这时执行bgrewriteaof，查看aof文件大小： -rw-r--r-- 1 root root 50 2月 21 23:24 redis-63791.aof 结论：执行bgrewriteaof后，重复的写操作被删除了！！

同时log如下：fork一个子进程操作的

注意：当aof文件很大的时候执行bgrewriteaof会导致性能问题，为此redis也提供了对应策略：

auto-aof-rewrite-percentage 50 # 配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写

auto-aof-rewrite-min-size 20M # 配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时，才会进行 AOF 重写

这个是不是和rdb持久化中配置自动执行bgsave一个类型！！！

 

AOF 的优点

AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。（保证数据完整性，对数据要求高的建议使用）

AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。（容易修改写入的命令）

AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

 

AOF 的缺点

对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。

虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。

RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在

 

备注：

1. https://redis.io/topics/persistence
2. https://redis.io/topics/protocol