Redis持久化——AOF

AOF（Append Only File）

以日志的形式来记录每个写操作(增量保存)，将Redis执行过的所有写指令记录下来(读指令不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。【默认不开启】

AOF和RDB同时开启，系统默认读取AOF的数据。

 

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内

（2) AOF缓冲区根据AOF持久化策略[always、everysec、no]将操作sync同步到磁盘的AOF文件中

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

 

AOF备份恢复：

同rdb一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载

异常恢复：

修改默认的appendonly no改为yes

如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复

备份写坏的AOF文件

恢复：重启redis服务，然后重新加载

 

AOF同步频率设置

appendfsync always：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性较好

appendfsync everysec：每秒记入日志一次，如果宕机，本秒的数据可能丢失

appendsync no：redis不主动进行同步，把同步时机交给操作系统

 

Rewrite压缩

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

AOF文件持续增长且过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename), 把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作

 

优点：

备份机制更加稳健，丢失数据概率更低

可读的日志文件，通过操作AOF文件，可以处理误操作，aof文件损坏可以修复

缺点：

记录数据和操作，比起rdb占用更多的磁盘空间，

恢复速度要慢，

每次读写都同步的话，有一定的性能压力，

存在个别Bug，造成恢复不能。