Redis的AOF持久化

AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。

流程

所有的写入命令会追加到aof_buf（缓冲区）中；
AOF缓冲区根据对应的策略向硬盘做同步操作；
随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的；
当Redis服务器重启时，可以加载AOF文件进行数据恢复；

命令写入

AOF命令写入的内容直接是文本协议格式。

AOF的两个疑惑：

AOF为什么直接采用文本协议格式？
- 文本协议具有很好的兼容性。
- 开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
- 文本协议具有可读性，方便直接修改和处理。
AOF为什么把命令追加到aof_buf中？

Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

文件同步

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制。

always:命令写入aof_buf后调用系统fsync操作同步到AOF文件中，fsync完成后线程返回；
everysec:命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次；
no:命令写入aof_buf后调用系统write操作，不对AOF文件做fsync操作，同步硬盘操作由操作系统负责，通常最长同步周期为30秒；
write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。

重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。重写后的AOF文件为什么可以变小？有如下原因：

进程内已经超时的数据不再写入文件。
旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。 AOF重写过程可以手动触发和自动触发：

手动触发：直接调用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
- auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
- auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。
- 自动触发时机=aof_current_size>auto-aof-rewrite-minsize &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

AOF重写流程

rewrite

1、执行AOF重写请求。

如果当前进程正在执行AOF重写，请求不执行并返回如下响应：

  ERR Background append only file rewriting already in progress

如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：

  Background append only file rewriting scheduled

2、父进程执行fork创建子进程，开销等同于bgsave过程。
3.1、主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2、由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4、子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
5.2、父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3、使用新AOF文件替换老文件，完成AOF重写。

重启加载

AOF和RDB文件都可以用于服务器重启时的数据恢复。

AOF持久化开启且存在AOF文件时，优先加载AOF文件；
AOF关闭或者AOF文件不存在时，加载RDB文件；
加载AOF/RDB文件成功后，Redis启动成功;
AOF/RDB文件存在错误时，Redis启动失败并打印错误信;

文件校验

对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复。

AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动。

AOF追加阻塞

当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性能和数据安全性。对于这种方式，Redis使用另一条线程每秒执行fsync同步硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞。

主线程负责写入AOF缓冲区；
AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间；
主线程负责对比上次AOF同步时间：
- 如果距上次同步成功时间在2秒内，主线程直接返回；
- 如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成；

AOF阻塞问题：

everysec配置最多可能丢失2秒数据，不是1秒；
如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率；

AOF阻塞问题定位：

发生AOF阻塞时，Redis输出如下日志，用于记录AOF fsync阻塞导致拖慢Redis服务的行为;

  Asynchronous AOF fsync is taking too long (disk is busy).
  Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis

每当发生AOF追加阻塞事件发生时，在info Persistence统计中， aof_delayed_fsync指标会累加，查看这个指标方便定位AOF阻塞问题;
AOF同步最多允许2秒的延迟，当延迟发生时说明硬盘存在高负载问题，可以通过监控工具如iotop，定位消耗硬盘IO资源的进程;

优化AOF追加阻塞问题主要是优化系统硬盘负载。

Redis-02丨Redis的AOF持久化