Redis之持久化AOF

AOF持久化

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

开启AOF

默认是不开启AOF的，需要我们在redis.conf配置文件进行修改，vim redis.conf

AOF相关配置

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

关闭rdb持久化

使用AOF持久化的话，先关闭rdb的持久化，在redis.conf配置文件中

重启服务

另外一个连接窗口，查看appendonly.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 的性能造成较大的影响。

使用bgrewriteaof命令，可以解决重复的内容

再次查看appendonly.aof文件，就是最新的了

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