Redis系列四：Redis的持久化之（2）AOF

AOF

　　AOF的全称是Append Only File，其工作原理是以日志的形式记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初

会读取该文件重新构建数据。换言之，redis重启的话就会根据日志文件中的内容，将写指令从前到后执行一次以完成数据的恢复工作。

 

AOF保存的是什么？

　　AOF保存的是appendonly.aof文件。

 

AOF的配置在哪里？

redis.conf文件中，默认是no，即redis默认的持久化策略是RDB，如果想修改redis的持久化方式为aof，需要将no改为yes

 

 

AOF正常恢复

第一步：修改redis.conf文件中的appendonly no，改为yes；

第二步：将有数据的aof文件复制一份到对应目录（命令：CONFIG GET dir）;

第三步：重启redis，重新加载

 

AOF异常恢复

第一步：修改redis.conf文件中的appendonly no，改为yes；

第二步：备份被写坏的AOF文件

第三步：修复写坏的AOF文件，命令为：redis-check-aof --fix appendonly.aof

 

 第四步：重启redis，重新加载

 

Rewrite

是什么？

　　AOF采用文件追加的方式，随着时间的推移文件不可避免的会越来越大，为了避免出现此情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复

数据的最小指令集，可以使用命令bgrewriteof

重写原理？

　　AOF文件持续增长而过大时，会fork出一条进程来将文件重写（也是先写临时文件，最后在rename），遍历新进程的内存中的数据，每条记录有一条set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将

整个内存数据库中的数据用命令的方式重写了一个新的aof文件，这点和快照有点类似。

触发机制？

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

 

同步方式？

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

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

不同步：appendfsync no   从不同步

 

AOF VS RDB

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

　　aof运行效率要慢于rdb，但是同步策略效率较好，不同步效率和rdb相同；

 

总结