Redis AOF持久化

1. AOF持久化本质是采用日志的形式来记录每个写操作，并追加到对应的.aof文件中。
2. Redis重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，会忽略掉RDB存储载入。
3. Redis服务默认没有开启AOF功能，打开redis.conf文件，找到 APPEND ONLY MODE 对应内容：
   1）修改appendonly值为yes；
   2）修改appendfilename指定本地数据库文件名，默认值为 appendonly.aof（可选）；
   3）指定更新日志条件；
     appendfsync always：Redis在每个事件循环都要将AOF缓冲区中的所有内容写入到AOF文件，并且同步AOF文件，所以always的效率是appendfsync选项三个值当中最差的一个，但从安全性来说，也是最安全的。当发生故障停机时，AOF 持久化也只会丢失一个事件循环中所产生的命令数据；
     appendfsync everysec：Redis在每个事件循环都要将AOF缓冲区中的所有内容写入到AOF文件中，并且每隔一秒就要在子线程中对AOF文件进行一次同步。从效率上看，该模式足够快。当发生故障停机时，只会丢失一秒钟的命令数据；
     appendfsync no：Redis在每一个事件循环都要将AOF缓冲区中的所有内容写入到AOF文件。而AOF文件的同步由操作系统控制。这种模式下速度最快，但是同步的时间间隔较长，出现故障时可能会丢失较多数据；
4. AOF重写机制：由于AOF采用追加日志记录操作，所以随着Redis长时间运行，.aof文件体积会越来越大，可能对Redis甚至宿主服务器造成影响。AOF文件重写（rewrite）功能将创建一个新的.aof文件替换旧文件，新文件中将旧文件中相同操作合并成一条记录（对同一对象的操作），所以新文件的体积通常比旧文件的体积要小得很多。

AOF Rewrite的触发机制主要有以下三个：

1. 手动调用bgrewriteaof命令，如果当前AOF/RDB数据持久化没有在执行，则本次rewrite会推迟执行，那么执行，反之，等当前AOF/RDB数据持久化结束后执行；
2. 在Redis配置文件redis.conf中，用户设置了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数，并且当前AOF文件大小server.aof_current_size大于auto-aof-rewrite-min-size(server.aof_rewrite_min_size)，同时AOF文件大小的增长率大于auto-aof-rewrite-percentage(server.aof_rewrite_perc)时，会自动触发AOF Rewrite；
3. 用户设置“config set appendonly yes”开启AOF的时，调用startAppendOnly函数会触发AOF Rewrite；

AOF的优缺点

• 优点：
  1）AOF更好保证数据不会被丢失，最多只丢失一秒内的数据；
  2）通过fork一个子进程处理持久化操作，保证了主进程不会进程io操作，能高效的处理客户端的请求；
  3）AOF的日志文件的记录可操作性非常的高，可以通过修改aof的日志文件，恢复到指定场景。
• 缺点：
  1）对于相同数量的数据集而言，AOF文件通常要大于RDB文件；
  2）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快；
  3）AOF在运行效率上往往会慢于RDB。

混合持久化

在Redis4.0后可以通过aof-use-rdb-preamble配置项打开混合开关。
  混合持久化也是通过bgrewriteaof来完成的，不同的是当开启混合持久化时，fork出的子进程先将共享内存的数据以RDB方式写入aof文件中，然后再将重写缓冲区的增量命令以AOF方式写入文件中。写入完成后通知主进程统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的AOF文件。
  新的AOF文件前半段是以RDB格式的全量数据后半段是AOF格式的增量数据。
  由于绝大部分的格式是RDB格式，加载速度快，增量数据以AOF方式保存，数据更少的丢失。

2020-05-12