Redis持久化之AOF

在上篇文章中介绍了快照持久化，对于它的优缺点大家也有所有了解了。本文主要介绍redis持久化中的另一种方式AOP(Append only file)持久化

---

Redis持久化之快照(RDB)

---

AOF持久化

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

开启AOF

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

AOF相关的配置

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

参数	值	说明
appendonly	yes	是否开启AOF持久化
appendfilename	“appendonly.aof”	存储的文件的名称
appendfsync	everysec	同步频率 everysec 每隔一秒钟持久化一次 always 每执行一条命令持久化一次 no 持久化的时机交给操作系统处理
no-appendfsync-on-rewrite	no	执行压缩时是否执行同步操作
auto-aof-rewrite-percentage	100	当前AOF文件超过上次AOF文件的百分比后才进行持久化操作
auto-aof-rewrite-min-size	64mb	自定执行AOF操作文件最小的大小要达到的大小

关闭快照(RDB)持久化

修改如下配置即可

save ""
#save 900 1
#save 300 10
#save 60 10000

验证

重启服务

执行简单的命令操作

我们可以看到append.aof文件中存储的内容就是我们执行的命令

AOF持久化备份的注意点

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

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 的优点

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.如果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持久化同步，但如果主从都挂掉，影响较大~

~好了本文到此为止，
更多资料欢迎参考官网手册