AOF---Redis的持久化操作

AOF（Append Only File）

是什么

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

AOF 默认保存的是 appendonly.aof 文件

AOF默认不开启

aof文件的保存路径同rdb的路径一致

AOF同步频率设置

第一行：始终同步，每次redis的写入都会立刻记入日志；（性能较差但数据完整性较好）

第二行：每秒同步

第三行：不主动进行同步，把同步时机交给操作系统

AOF和RDB同时开启

系统默认读取AOF的数据（数据不会存在丢失）

AOF启动/修复/恢复

• 正常恢复

  • 启动：设置Yes 修改默认的appendonly no，改为yes

  • 将有数据的 aof 文件复制一份保存到对应目录(config get dir)

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

• 异常恢复

  • 启动：设置Yes 修改默认的appendonly no，改为yes

  • 备份被写坏的AOF文件

  • 修复：redis-check-aof --fix进行修复 + AOF文件

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

rewrite（AOF 重写）

是什么

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

重写原理

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的 Set 语句。重写 aof 文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似

触发机制

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

重写流程

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

1.bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后在执行

2.主进程fork出子进程执行重写操作，保证主进程不会阻塞

3.子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失

4.子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息；主进程把aof_rewrite_buf中的数据写入到新的AOF文件

5.使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

AOF持久化流程 

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

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

3.AOF文件大小朝贡重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量

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

优势

• 备份机制更稳健，丢失概率更低
• 可读的日志文本，通过操作AOF文件，可以处理误操作

劣势

• 比起RDB占用更多的磁盘空间
• 恢复备份速度要慢
• 每次读写都同步的话，有一定的性能压力
• 存在个别Bug，造成恢复不能

总结

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

• AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以 redis 协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写（bgrewriteaof）,使得 AOF 文件的体积不至于过大

用哪个好

同时开启两种持久化方式

如果对数据不敏感，可以单独用RDB

不建议单独用AOF，因为可能会出现Bug

如果只是单独做纯内存缓存，可以都不用