上一篇博文给大家介绍了redis持久化的方式之一RDB，其中说到过RDB的缺陷是可能会导致数据丢失严重，所以redis的作者

由于强迫症又开发出了AOF来你补这一不足。好接下来我将为大家介绍AOF。

一、AOF是什么？

        AOF全称Append Only File，以redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

二、AOF保存的是appendonly.aof文件。

三、配置位置

1、appendonly no

是否使用AOF方式持久化数据（可以和RDB一起使用），AOF优先级更高。

2、appendfilename “appendonly.aof”

AOF持久化方式存储日志的文件名。

3、appendfsync everysec

AOF持久化策略，有三种取值：

- always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好；

- everysec：默认值，每秒同步记录，但如果一秒内宕机，有数据丢失；

- no：不同步。

4、no-appendfsync-on-rewrite no

重写时是否可以运行appendfsync，默认为no，保证数据安全性。

5、auto-aof-rewrite-min-size 100

当AOF文件大小是上次rewrite后大小的 x% 倍时再次重写，默认x为100，即AOF文件大小是上次rewrite后大小的一倍

时再次重写。

6、auto-aof-rewrite-percentage 64

第一次重写AOF文件时的文件大小，默认为64M。

四、AOF启动、修复、恢复

1、正常恢复：

- 启动：设置appendonly yes

- 将有数据的aof文件复制一份保存到对应目录（config get dir）

- 恢复：重启redis然后重新加载

2、异常恢复：

- 启动：设置appendonly yes

- 备份被写坏的AOF文件

- 修复：redis-check-aof --fix 进行修复，同理redis-check-dump --fix可以修复dump.rdb文件；

- 恢复：重启redis然后重新加载

五、AOF的rewrite（重写）

1、AOF的重写是什么？

AOF采用文件追加的方式，文件会越来越大。为避免出现文件无限大内容冗余的情况，新增了重写机制，当AOF文

件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令

bgrewriteaof 。

2、重写原理

AOF文件持续增长而过大时，会fork出一条新进程来讲文件重写（也是先写临时文件在rename），遍历新进程的内

存数据，每条记录有一条set语句。注意，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内

容用命令的方式重写了一个aof文件，这点和快照有点类似。

3、触发机制

Redis会记录上次重写时AOF文件的大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

六、优势

1、每修改同步：appendfsync always，同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。

2、每秒同步：appendfsync everysec，异步操作，每秒记录，如果一秒内宕机，有数据丢失。

3、不同步：appendfsync no，从不同步。

七、劣势

1、相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；

2、AOF运行效率要慢于rdb，每秒同步效率较好，不同步效率和rdb相同。

八、总结

1、RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储；

2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以

redis协议追加保存每次写的操作到文件末尾；

3、redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大；

4、只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式；

5、同时开启两种持久化方式

- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要

比RDB文件保存的数据集要完整；

- RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件恢复数据。那要不要只使用AOF呢？作者建议不要，

因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的bug，留着作

为一个万一的手段。

6、性能建议

- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留

save 900 1这条规则；

- 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以

了。代价一是带来了持续的IO，二是AOF重写的最后将重写过程中产生的新数据写入新文件造成的堵塞几乎是不可避免

的。只要硬盘许可，应该尽量减少AOF重写的频率，AOF重写的基础大小默认值64M 太小了，可以设到5G以上。默认

超过原大小100%大小时重写可以改到适当的数值。

- 如果不Enable AOF，仅靠Master-Slave复制实现高可用性也可以。能省掉一大笔IO也减少了重写时带来的系统波动。代

价是如果Master和Slave同时挂掉，会丢失十几分钟的数据。启动脚本也要比较Master和Slave中的RDB文件，载入较新

的那个。新浪微博就选用了这种架构。