Redis的AOF持久化分析

这篇文章主要讲解了“redis的AOF持久化分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Redis的AOF持久化分析”吧！

创新互联建站十载专注成都高端网站建设按需策划服务,为客户提供专业的成都网站制作,成都网页设计,成都网站设计服务;创新互联建站服务内容包含成都网站建设,小程序开发,软件开发,网络营销推广,网络运营服务及企业形象设计;创新互联建站拥有众多专业的高端网站制作开发团队,资深的高端网页设计团队及经验丰富的架构师高端网站策划团队;我们始终坚持从客户的角度出发,为客户量身订造网络营销方案，解决网络营销疑问。

AOF持久化

与快照持久化不同，AOF持久化是将被执行的命令写到aof文件末尾，在恢复时只需要从头到尾执行一遍写命令即可恢复数据，AOF在redis中默认也是没有开启的，需要我们手动开启，开启方式如下：

打开redis.conf配置文件，修改appendonly属性值为yes，如下：

appendonly yes

另外几个和AOF相关的属性如下：

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

这几个属性的含义分别如下：

1.appendfilename表示生成的AOF备份文件的文件名。
2.appendfsync表示备份的时机，always表示每执行一个命令就备份一次，everysec表示每秒备份一次，no表示将备份时机交给操作系统。
3.no-appendfsync-on-rewrite表示在对aof文件进行压缩时，是否执行同步操作。
4.最后两行配置表示AOF文件的压缩时机，这个我们一会再细说。

同时为了避免快照备份的影响，我们将快照备份关闭，关闭方式如下：

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

此时，当我们在redis中进行数据操作时，就会自动生成AOF的配置文件appendonly.aof，如下：

注意此时没有dump.rdb文件，这时我们将redis关闭并重启，会发现之前的数据都还在，这就是AOF备份的结果。

AOF备份的几个关键点

1.通过上面的介绍，小伙伴们了解到appendfsync的取值一共有三种，我们在项目中首选everysec，always选项会严重降低redis性能。
2.使用everysec，最坏的情况下我们可能丢失1秒的数据。

AOF文件的重写与压缩

AOF备份有很多明显的优势，当然也有劣势，那就是文件大小。随着系统的运行，AOF的文件会越来越大，甚至把整个电脑的硬盘填满，AOF文件的重写与压缩机制可以在一定程度上缓解这个问题。
当AOF的备份文件过大时，我们可以向redis发送一条bgrewriteaof命令进行文件重写，如下：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
(0.71s)

bgrewriteaof的执行原理和我们上文说的bgsave的原理一致，这里我就不再赘述，因此bgsave执行过程中存在的问题在这里也一样存在。

bgrewriteaof也可以自动执行，自动执行时间则依赖于auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置，auto-aof-rewrite-percentage 100表示当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据，同时还要求AOF文件的大小至少要大于64M(auto-aof-rewrite-min-size 64mb)。

最佳实践

1.如果redis只做缓存服务器，那么可以不使用任何持久化方式。
2.同时开启两种持久化方式，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；RDB的数据不完整时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ 作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
3.因为RDB文件只用作后备用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
4.如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
5.如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

感谢各位的阅读，以上就是“Redis的AOF持久化分析”的内容了，经过本文的学习后，相信大家对Redis的AOF持久化分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！