Reids持久化-AOF

简介

AOF（Appen Only File）
以日志的形式记录服务器所处理的每一个更改操作，但操作过多。aof文件过大时，加载文件恢复数据会非常慢，为解决该问题，Redis支持aof文件重写，通过重写aof可以生成以给恢复当前数据的最少命令集。

所以流程大致分为两步，一是命令的实时写入，二是对aof文件的重写

命令写入流程：命令写入=》追加到aof_buf =》同步到aof磁盘（考虑到磁盘IO性能增加缓冲）

aof重写可以手动或自动触发

命令触发：bgrewriteaof
自动触发：根据配置规则来触发（整体时间和Redis的定时任务频率有关系）

在写入aof日志文件时，如果reids服务宕机，则日志文件会出格式错误，重启服务时，服务器会拒绝载入这个aof文件，此时可以通过以下命令修复aof并恢复数据
redis-check-aof -fix file.aof

RDB在redis.con中的配置

• appendonly yes 开启
• appendfilename "appendonly.aof" 文件名称
• appendfsync everysec 同步方式
  • always: 把每个明亮都立即同步到aof，很慢 但是安全
  • everysec: 每秒同步一次，是折中方案
  • no:redis不处理交给os来处理，非常快，但是也是最不安全的
• no-appendfsync-on-rewrite no 重写期间是否同步
• 重写触发
  • auto-aof-rewrite-precentage 100 百分比
  • auto-aof-rewrite-min-size 64mb 最小数据量
• aof-load-truncated 加载aof出错时如何处理
  • yes：出错时向客户端写入log后继续执行
  • no: 出错就停止执行
• aof-rewrite-incremental-fsync yes 文件重写策略
• aof-use-rdb-preamble yes
• 当RDB与AOP两种方式都开启时，redis启动时会优先使用AOF日志来恢复数据，因为AOF保存文件比RDB文件更完整
• redis4.0提供了一个混合持久化的选择，将rdb文件的内容和增量的aof日志存在一起，重启时先加载rdb，再重放aof,以达到最大效率。

AOF-Fork原理

image.png

在重写期间，由于主机进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失

为了把重写期间的响应写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据

重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并

AOF文件直接采用文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复

AOF性能分析

优点

• AOP只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗内存较少
• 数据安全性较高

缺点

• AOF方式生成的日志文件太大，即使通过AOF重写，文件体积仍然很大
• 恢复数据的速度比RDB慢