Redis持久化之AOF

一、是什么

• 以日志的形式来记录每个写操作，将Redis执行过得所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis启动的话就根据日志文件的内容将写执行从前到后执行一次以完成数据的恢复工作

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

• 演示以及配置：
  • 修改配置文件关闭RDB，打开AOF：
  • 
  • 
  • 启动Redis，创建对象，并且恶意破坏：
  • 
  • 
  • 代开appendonly.aof文件：
  • 
  • 这里需要打开appendonly.aof文件，删除最后一行：
  • 
  • 这里如果不删除appendonly.aof 的最后一行，那么会显示如下图所示：
  • 
  • 重新启动Redis，并使用命令 keys * 进行查看所有的key：
  • 
  • 这样就恢复成功了
  • 注意：如果我们不关闭RDB，那么我们在 appendonly.aof 中加入乱码，那么启动Redis会显示如下图所示
  • 

  • **************************************************************

  • *所以AOF和RDB两者可以共存，它启动后先加载AOF*

  • **************************************************************

  • 修复上述乱码：
    • 输入命令：./redis-check-aof --fix appendonly.aof
    • 
    • 重新启动Redis：
    • 

三、配置位置

• appendonly：打开AOF，只要将 appendonly 后边的 no 改为 yes
• 

四、AOF启动、修复、恢复

• 正常恢复：
  • 启动：设置yes【修改默认的appendonly no 变为 yes】
  • 将有数据的aof文件复制一份到对应目录（config get dir）
  • 恢复：重启Redis然后重新加载
• 异常恢复：
  • ​​​​​​​启动：设置yes
  • 备份被写坏的AOF文件
  • 修复，输入命令：./redis-check-aof --fix appendonly.aof 进行修复
    • ​​​​​​​注意：也可以修复RDB： ./redis-check-dump --fix dump.rdb
  • 恢复：重启redis然后重新加载

五、Rewrite

• 是什么：
  • AOF 采用文件追加方式，文件会越来越多为避免出现此情况，新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保存可以恢复数据的最小指令集，可以使用命令bgrewriteaof
• ​​​​​​​重写原理：
  • ​​​​​​​AOF文件持续增长而过大时，会Fork出一条新的进程来讲文件重写（也是先写临时文件最后写rename），遍历新进程的内存中的数据，每条记录有一条的Set语句。重写aof文件操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
• 触发机制：
  • Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次 rewrite 后大小的一倍且文件大于64M时触发
  • 

六、优势

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

七、劣势

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

八、总结

•