Redis AOF 持久化学习笔记

本文主要是介绍Redis AOF 持久化学习笔记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章 Redis 快照持久化学习笔记介绍 Redis 快照持久化的功能，除了快照持久化外，Redis 还提供了 AOF（Append Only File）持久化功能。与快照持久化通过直接保存 Redis 的键值对数据不同，AOF 持久化是通过保存 Redis 执行的写命令来记录 Redis 的内存数据。

AOF 持久化的原理
理论上说，只要我们保存了所有可能修改 Redis 内存数据的命令（也就是写命令），那么根据这些保存的写命令，我们可以重新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的。
Redis AOF 持久化原理如图 1 与图 2 所示。

图1：Redis 将写命令保存到 AOF 文件中

图2：Redis 利用 AOF 文件还原内存数据

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

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysecappendonly：是否打开 AOF 持久化功能
appendfilename：AOF 文件名称
appendfsync：同步频率，可选配置如表1所示选项    同步频率
always    每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能
everysec    每秒执行一次同步，显式地将多个写命令同步到硬盘
no    让操作系统来决定应该何时进行同步

AOF 文件的生成过程具体包括命令追加，文件写入，文件同步三个步骤。
Redis 打开 AOF 持久化功能后，Redis 在执行完一个写命令后，都会将执行的写命令追回到 Redis 内部的缓冲区的末尾。这个过程是命令的追加过程。
接下来，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程。只有经过文件同步过程，AOF 文件才在硬盘中真正保存了 Redis 的写命令。appendfsync 配置选项正是用来配置将写命令同步到文件的频率的，各个选项的值的含义如表 1 所示。

AOF 文件
前面我们提到，AOF 持久化是通过 AOF 文件来实现的，那么 AOF 里面是如何保存 Redis 的写命令的呢？
假设我们对一个空的 Redis 数据库执行以下命令：

set msg hello
set site leehao.me

执行后，Redis 数据库保存了键 msg 与 site 的数据。打开保存的 AOF 文件appendonly.aof（AOF 文件的路径和名称由 redis.conf 配置，具体可以参考上面 AOF 配置的描述），可以看到其内容为：

*2
$6
SELECT
$1
0
*3
$3
set
$3
msg
$5
hello
*3
$3
set
$4
site
$9
leehao.me

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

重写 / 压缩 AOF 文件
由于 Redis 会不断地将被执行的命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积会越来越大。另外，如果 AOF 文件的体积很大，那么还原操作所需要的时间也会非常地长。
为了解决 AOF 文件越来越大的问题，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会移除 AOF 文件中冗余的命令来重写 AOF 文件，使 AOF 文件的体积变得尽可能地小。
BGREWRITEAOF 的工作原理和快照持久化命令 BGSAVE 的工作原理类似，Redis 会创建一个子进程来负责对 AOF 文件进行重写。
值得注意的是，进行 AOF 文件重写时，如果原来的 AOF 文件体积已经非常大，那么重写 AOF 并删除旧 AOF 文件的过程将会对 Redis 的性能造成较大的影响。
为此，Redis 提供auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项来对 AOF 重写进行配置。auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项的含义可以参考 redis.conf 配置中的详细说明，具体来说，auto-aof-rewrite-percentage配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写，而auto-aof-rewrite-min-size则配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时，才会进行 AOF 重写。

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 没有存在。
参考资料
Redis 实战，Josiah L. Carlson 著，黄健宏译，人民邮电出版社，2015年
Redis 设计与实现，黄健宏著，机械工业出版社，2015年
https://redis.io/topics/persistence
https://redis.io/topics/protocol
---------------------
作者：haozlee
来源：CSDN
原文：https://blog.csdn.net/lihao21/article/details/75269622
版权声明：本文为博主原创文章，转载请附上博文链接！