Redis数据持久化之AOF

1. AOF简介

AOF(Append Only File),即以日志的形式来记录每个写操作，将Redis成功执行的所有写指令记录下来，读操作不记录，保存时只允许追加文件但是不可以改写文件。Redis重启后就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2. 相关配置

使用vim打开redis.conf，使用快捷匹配模式，输入/APEND，即看到AOF相关配置，如下：

下面来看看AOF的常用配置：

appendonly no

AOF在Redis中默认是没有开启的，需要我们将appendonly属性值修改为为yes来手动开启。

appendfilename "appendonly.aof"

appendfilename表示生成的AOF备份文件的文件名。这个使用默认的appendonly.aof即可。

# appendfsync always
appendfsync everysec
# appendfsync no

appendfsync表示备份的时机，三个属性值的作用如下：

1. always表示每执行一个命令就备份一次，会减弱Redis的性能但数据完整性较好。
2. everysec表示每秒备份一次（默认）。
3. no表示将备份时机交给操作系统自动调度，写操作后不会有fsync调用。

no-appendfsync-on-rewrite no

no-appendfsync-on-rewrite表示rewrite时是否对aof新记录的append暂缓使用文件同步策略,默认为no,表示"不暂缓",新的aof记录仍然会被立即同步。这样保证了数据安全性。

下面两条配置是关于AOF文件重写的基准值：

auto-aof-rewrite-percentage 100

auto-aof-rewrite-percentage表示触发AOF重写的最小增长比例。设置为0表示不自动重写AOF文件，重写是为了使AOF体积保持最小，而确保保存最完整的数据。默认为增长了一倍即重写AOF文件。

auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-min-size表示触发AOF重写的最小文件大小，默认为64MB。

aof-load-truncated yes

aof-load-truncated的默认值为 yes。当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以重启Redis服务器。

aof-use-rdb-preamble yes

aof-use-rdb-preamble表示是否开启混合存储，默认是开启的。开启后Redis保证RDB转储跟AOF重写不会同时进行。当Redis启动时，即便RDB和AOF持久化同时启用且AOF，RDB文件都存在，则Redis总是会先加载AOF文件，这是因为AOF文件被认为能够更好的保证数据一致性。

3. 相关操作

3.1 启动

在配置文件中redis.conf中修改appendonly为yes，重新启动Redis，如下：

127.0.0.1:6379> keys *
1) "k1"
2) "k3"
3) "k2"
127.0.0.1:6379> shutdown save
not connected> exit
[root@localhost bin]# redis-server /myredis/redis.conf
[root@localhost bin]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)

查看redis的目录，可以看到新生成的appendonly.aof文件：

从返回的是(empty list or set)就可以看到，当rdb和aof文件都有时，Redis是先加载appendonly.aof文件的。因为appendonly.aof是新创建的，所以里面为空。

3.2 修复

首先进行一些写操作，如下：

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2 
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> shutdown save
not connected> exit

使用vi打开appendonly.aof，查看appendonly.aof保存的内容，如下：

破坏appendonly.aof文件里的内容格式，如下：

再次启动Redis，可以看到启动失败，无法进入Redis控制台

这就需要用到redis-check-aof --fix指令，如下：

这样就成功修复了appendonly.aof文件。
再次启动Redis，就重新加载appendonly.aof文件，就能成功启动了，如下：

3.3 恢复

当redis目录的appendonly.aof无法修复时，将之前备份好的aof文件保存到对应目录下即可。获取redis安装目录，如下：

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

4. AOF的重写

因为随着我们的使用，而AOF是以追加的方式进行保存的，文件会变得越来越大，AOF的重写可以缓解这个问题。

4.1 重写原理

当AOF文件过大时，服务器会fork出一条新进程来进行文件重写。重写AOF文件的操作，并不是读取旧的AOF文件，而是遍历整个内存中的数据库的所有键，然后只有一个命令来进行记录对应的键值对，代替之前记录该键值对的多个命令。操作完成后将这个新的AOF文件覆盖旧的。这样就只保留了可以恢复数据的最小指令集了。

4.2 触发机制

一种方式是自动执行，其依赖于auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置，默认配置如下：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：

• 没有BGSAVE命令（RDB持久化）/AOF持久化在执行；
• 没有BGREWRITEAOF在进行；
• 当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB），或者在redis.conf配置了auto-aof-rewrite-min-size大小；
• 当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）

如果前面三个条件都满足，并且当前AOF文件大小比最后一次AOF重写时的大小要大于指定的百分比，那么触发自动AOF重写。

除了前面配置讲到的两个默认的触发条件，还有一个命令BGREWRITEAOF来触发AOF重写， 使用如下：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

因为Redis是使用单线程处理命令，而AOF重写会进行大量的写操作，所以当AOF文件数据庞大时，使用这条命令会导致线程的长时间阻塞，Redis无法再接受客户端发来的命令请求了。

---

深入学习理解AOF重写：https://blog.csdn.net/hezhiqiang1314/article/details/69396887?utm_source=distribute.pc_relevant.none-task

---

5. 总结

1. 如果redis只做缓存服务器，那么可以不使用任何持久化方式。
2. 当同时开启两种持久化方式时，当Redis重启服务器后会优先加载AOF文件来恢复原始的数据，但是作者并不建议只使用AOF持久化，因为RDB更适合用于备份数据库，而AOF不断变换数据导致备份性能消耗大。

下面说一下AOF的优缺点：

5.1 优点

在最坏的情况下也只会丢失不超过两秒数据，恢复数据只需要加载自己的AOF文件就可以了。

5.2 缺点

1. 相同数据集的数据而言，AOF文件要远大于RDB文件，恢复速度慢于RDB。
2. AOF运行效率要慢于RDB，AOF持久化的方式不可避免的有大量的读写操作。
3. AOF重写过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF重写的频率。