[大数据]【Redis持久化原理之AOF(Append Only File)】

Redis持久化原理之AOF(Append Only File)

知识回顾:

通过对Redis中的String的命令做了充分的讲解以及实践学习
通过对Redis中String类型之Bit命令的详解以及Bit命令的实践进行了学习
通过对Redis中的Hash类型以及Hash中常用命令的实践学习
通过对Redis之List类型的详解&List类型中常用命令的实践的学习
通过对Redis之Set类型的详解&Set类型中常用命令的实践的学习
通过对Redis之ZSet类型的详解&ZSet类型中常用命令的实践的学习
通过对Redis中消息的发布和订阅以及命令的实践学习
通过对Redis中事务Multi命令及监控键值Watch命令的实践学习
通过对Redis持久化原理之快照版本RDB的学习
接下来的学习任务:
接下来我们要学习的内容是:Redis持久化原理之AOF(Append Only File)。

Redis中String类型内容请看这里呦:
【Redis之String类型的详解&String类型中常用命令的实践】
Redis中String类型是Bit命令内容请看这里呦:
【Redis中String类型之Bit命令的详解&Bit命令的实践】
Redis之Hash类型的详解&Hash类型中常用命令的实践请看这里呦:
【Redis之Hash类型的详解&Hash类型中常用命令的实践】
Redis之List类型的详解&List类型中常用命令的实践请看这里呦:
【Redis之List类型的详解&List类型中常用命令的实践】
Redis之Set类型的详解&Set类型中常用命令的实践请看这里呦:
【Redis之Set类型的详解&Set类型中常用命令的实践】
Redis之Zset类型的详解&Zset类型中常用命令的实践请看这里呦:
【Redis之ZSet类型的详解&ZSet类型中常用命令的实践】
Redis中消息的发布和订阅以及命令的实践请看这里呦:
【Redis中消息的发布和订阅】
Redis中事务Multi命令及监控键值Watch命令的实践请看这里呦:
【Redis中事务Multi命令及监控键值Watch命令】
Redis持久化原理之快照版本RDB的学习请看这里呦:
【Redis持久化原理之快照版本RDB】

Redis持久化的基本概念

所谓的持久化就是保持我们的数据不丢失，将数据通常保存在我们的硬盘中。在Redis中持久化的方式有两种，一种是快照持久化，一种是AOF持久化，各有各的优缺点，在项目中我们得根据实际的情况来选择具体的持久化方式。本篇文章主要是学习AOF持久化，后续会学习RDB持久化。

AOF持久化

AOF持久化与RDB快照持久化通过直接保存 Redis 的键值对数据不同，AOF 持久化是通过保存 Redis 执行的写命令来记录 Redis 的内存数据。理论上说，只要我们保存了所有可能修改 Redis 内存数据的命令（也就是写命令），那么根据这些保存的写命令，我们可以重新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的。

AOF持久化相关的配置文件

在redis中AOF默认是关闭的，我们需要修改配置文件来开启AOF。

# appendonly 默认是no 是关闭的 我们需要修改为yes 
appendonly yes
# 设置文件的名称
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
# 设置同步频率
appendfsync everysec
# appendfsync no
# 执行压缩时是否执行同步操作
no-appendfsync-on-rewrite no
# 当前AOF文件超过上次AOF文件的百分比后才进行持久化操作
auto-aof-rewrite-percentage 100
# 自定执行AOF操作文件最小的大小要达到的大小
auto-aof-rewrite-min-size 64mb

AOF配置文件的相关参数

AOF持久化备份的注意点

1.appendfsync的取值有三个，分别是everysec，always和no，在这里我们推荐使用everysec，不推荐使用always。因为always会严重影响服务器的性能。
2.everysec最坏的情况也就只会丢失1秒的数据，影响在可控范围之内。

AOF重写压缩过程可以手动触发和自动触发

手动触发：直接调用bgrewriteaof命令

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

• auto-aof-rewrite-min-size: 限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的。
• auto-aof-rewrite-percentage: 当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。

由于 Redis 会不断地将被执行的命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积会越来越大。另外，如果 AOF 文件的体积很大，那么还原操作所需要的时间也会非常地长。
为了解决 AOF 文件越来越大的问题，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会移除 AOF 文件中冗余的命令来重写 AOF 文件，使 AOF 文件的体积变得尽可能地小。
BGREWRITEAOF 的工作原理和快照持久化命令 BGSAVE 的工作原理类似，Redis 会创建一个子进程来负责对 AOF 文件进行重写。
值得注意的是，进行 AOF 文件重写时，如果原来的 AOF 文件体积已经非常大，那么重写 AOF 并删除旧 AOF 文件的过程将会对 Redis 的性能造成较大的影响。

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

为此，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 的优点

1. AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已
2. AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
3. AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

AOF 的缺点

1. 对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
2. 虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
3. RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

推荐使用Redis持久化的一些建议

1.如果redis仅仅是用来做为缓存服务器的话，我们可以不使用任何的持久化。
2.一般情况下我们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。
3.在主从节点中，RDB作为我们的备份数据，只在salve(从节点)上启动，同步时间可以设置的长一点，只留(save 900 1)这条规则就可以了。
4.开启AOF的情况下，主从同步是时候必然会带来IO的性能影响，此时我们可以调大auto-aof-rewrite-min-size的值，比如5GB。来减少IO的频率。
5.不开启AOF的情况下，可以节省IO的性能影响，这是主从通过RDB持久化同步，但如果主从都挂掉，影响较大！