Redis持久化之AOF

AOF是什么？

AOF是redis持久化的策略之一。
它以日志的形式来记录每个redis的写操作，将redis执行过的所有写指令记录下来（读操作不记录），并且它只允许往文件追加内容，而不可以改写文件。
redis在启动时，会读取该文件重新构建数据。也就是，redis重启时，会根据AOF日志文件的内容将写指令从头到尾执行一次，来完成数据的恢复工作
AOF保存的是appendonly.aof文件，redis.conf配置中，默认是no，不开启

配置

查看Redis配置中的第8点：APPEND ONLY MODE/追加

AOF启动/修复/恢复

• 启动
  启动：redis.conf文件中，把appendonly.aof no改成为yes
• 正常恢复（aof文件正常）
  1.首先已经启动了aof策略
  2.把有数据的aof文件复制一份保存到redis的启动目录config get dir
  3.重启redis，redis会主动读取aof文件恢复数据

注意.如果aof文件已损坏，那么在redis-cli启动时就会报错，比如Could not connect tot Redis at 127.0.0.1:6379: Connection refused

• 异常恢复（aof文件已损坏）
  1.首先已经启动了aof策略
  2.备份此时损坏的aof文件（以防以后可能需要）
  3.cd到redis根目录，找到redis-check-aof脚本；执行修复命令：redis-check-aof --fix appendonly.aof进行修复
  4.重启redis，redis会主动读取aof文件恢复数据

rewrite/重写

1、是什么？

由于AOF采用文件内容追加的方式，随着时间的增长，文件肯定会越来越大。为了避免出现这种情况，新增了rewrite/重写机制。
也就是当AOF文件的大小超过所设定的阙值时，redis2.4以后，就会自动对AOF文件的内容压缩，只保留可以恢复数据的最小指令集。但是也可以使用命令bgrewriteaof来手动启动。

2、触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发（实际应用肯定会调大这个值）

3、重写原理

• 在redis2.4以后，当AOF文件持续增长而过大，达到设定的阙值时，redis会自动fork一条新进程来讲aof文件进行重写，会遍历新进程的内存中数据，每条记录都有一条set语句。（采用先写个临时文件，最后再rename的方式）
• 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件（但是体积会比之前的小），和快照有些类似
• redis2.4以后，也可以使用bgrewriteaof来手动启动重写
• 即使重写执行失败，也不会有任何数据丢失，因为旧的AOF文件在bgrewriteaof成功之前不会被修改。

优势

有三种同步策略可选

• 每次修改都同步：appendfsync always
  同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
• 每秒都同步：appendfsync everysec
  异步操作每秒记录，如果一秒内宕机，那么会有数据丢失
• 不同步：appendfsync no
  不进行aof同步

劣势

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• Aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

appendonly.aof和dump.rdb共存

如果appendonly.aof和dump.rdb共存，那么在恢复数据时，会先读取appendonly.aof

小总结

aof小总结