Redis教程——持久化（AOF）

在上篇文章我们学习了Redis教程——持久化（RDB），这篇文章学习Redis教程——持久化（AOF）。

AOF

AOF持久化是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录）并以追加的方式写在日志中。

在Redis服务重启时，会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

工作原理如下图所示：

在Redis执行写操作时，不会立刻将写操作写入AOF文件中，而是先将写命令保存在AOF缓存区，根据写入策略将所有写操作保存在AOF文件中。

随着写入AOF内容的增加，AOF会根据规则进行命令的合并（重写），从而起到AOF文件压缩的目的，避免了文件膨胀。

「优势：」

• AOF有不同的写入策略，默认是每秒执行写入，其性能也是很好的，而且最多只能丢失一秒的数据；

• AOF日志是一个仅附加日志，不会出现寻道问题，不会在断电时出现损坏问题，即使有损坏，也可以通过redis-check-aof对AOF文件进行修复；

• 当AOF文件过大，Redis能在后台自动重写AOF，起到AOF文件压缩的目的，避免了文件膨胀；

• AOF文件内容易于理解，方便我们对其进行修改，从而达到我们想要的效果。

「劣势：」

• AOF文件通常比相同数据集的等效RDB文件大；

• AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同；

注意：AOF的优先级高于RDB，当AOF和RDB同时使用时，Redis重启时，只会加载AOF文件，不会加载RDB文件。

AOF配置

开启

默认情况下，AOF是关闭的，通过如下图配置开启AOF，

写入策略

AOF根据写入策略将所有写操作保存在AOF文件中，写入策略的配置如下：

其中：

配置项	写入时机	优点	缺点
always	同步写入	可靠性高，数据基本不丢失	每个写操作都要落盘，性能影响较大
everysec(默认)	每秒写入	性能适中	宕机时丢失1秒内的数据
no	操作系统控制写入	性能好	宕机时丢失数据较多

AOF文件

在Redis6及之前的版本，AOF文件有且只有一个，但在Redis7以后采用了多部分构成AOF的设计，也就是将原来单个AOF文件拆分为多个AOF文件，如下图所示：

其中：

• base：表示基础AOF，它一般由子进程通过重写产生，该文件最多只有一个；

• incr：表示增量AOF，它一般会在AOFRW开始执行时被创建，该文件可能存在多个；

• manifest：清单文件，用来跟踪、管理这些AOF文件，manifest文件单独保存在appenddirname配置路径。

AOF文件路径

AOF文件路径也是通过dir参数进行配置，在Redis6及之前的版本AOF文件和RDB文件的保存位置一样，就是dir的配置路径，但在Redis7版本之后作了一些调整，如下图所示：

简单来说就是在dir配置的路径上多加了appendonlydir文件夹，用来保存AOF文件。例如：dir配置的路径为/myRedis，那么AOF文件就保存在/myRedis/appendonlydir路径下。

演示

按照上面的操作开启AOF，并将dir配置为/myRedis时，我们执行Redis的写操作命令后，就会在myRedis/appendonlydir路径下生成AOF文件，如下图所示：

可以发现，当我们执行写操作后，Redis就会在myRedis文件夹创建appendonlydir文件夹并生成三个AOF文件，当我们再次执行写操作后，三个AOF文件，只有incr的AOF发生变化。

当发生宕机后，重启Redis服务，Redis就会根据AOF文件恢复数据。

异常恢复

当由于某些原因，AOF文件发生错误，例如：在incr的AOF文件中随便添加字符串，如下图所示：

重启Redis服务后，如下图所示：

由于AOF文件出现问题，导致连接不了Redis。这时可以使用redis-check-aof对AOF文件进行修复，命令语法格式如下：

redis-check-aof --fix 文件路径

如下图所示：

这样就成功修复了incr的AOF文件，接下来重启服务就可连接Redis并恢复数据。

重写机制

随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，保留可以恢复数据的最小指令集。

例如，Redis执行了如下写操作：

set k1 v1
set k1 v2
set k1 v3

不执行重写机制前，AOF文件记录了这三条写操作命令，执行重写机制后，Redis发现k1最终结果为v3，那么AOF文件只需记录最后一条写操作。

也就是说AOF文件重写是用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

其Redis配置如下：

当两个条件同时满足时，就会自动触发重写机制，

• 当前AOF文件大小比之前增长了1倍；

• 当AOF文件超过64mb；

也可以在客户端执行bgrewriteaof命令手动启动重写机制。

注意：当发生重写机制后，原来的appendonly.aof.1.base.rdb、appendonly.aof.1.incr.aof文件名变为appendonly.aof.2.base.rdb、appendonly.aof.2.incr.aof，而且文件大小都发生了改变。

好了，Redis教程——持久化（RDB）就讲到这里了，下篇文章我们学习Redis教程——持久化（AOF）。

公众号：白巧克力LIN

该公众号发布Python、数据库、Linux、Flask、Django、自动化测试、Git、算法、前端、服务器等相关文章！

- END -