Aof方式数据持久化

概述

AOF(Append Only File)：通过把所有写命令记录到一个设定好的日志文件中,记录redis数据，默认关闭。AOF里存储的是Redis自己定义的RESP协议格式的字符串。

AOF方式配置

# 是否开启AOF，默认关闭(no)
appendonly yes

# 指定 AOF 文件名
appendfilename appendonly.aof

# Redis支持三种刷写模式：
#每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。
#但该模式下速度也是最慢的，一般不推荐使用。
# appendfsync always 
#每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
appendfsync everysec 
#完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
# appendfsync no     
    
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,存在内存缓冲区+重写内存缓冲区中
#等子进程通知主进程rewrite完成后再从重写内存缓冲区写入重写的新AOF文件
#fsync(同步刷盘，从内存同步到磁盘)
#默认为no，建议yes
no-appendfsync-on-rewrite yes

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

AOF重写

重写的原因

AOF记录的是字符串，真正线上环境写操作是很多的，AOF的文件大小增加也是很快的，如果一个 AOF文件有10G了再去追加的时候会变得非常慢。 

重写的流程

 AOF功能工作原理和AOF重写原理总图：

具体流程：

1. 达到了重写的条件
2. 调用fork函数，复制出与主进程完全一致的一个子进程，主子进程共用同一块内存空间
3. 子进程调用aof_rewrite函数执行重写操作
4.在AOF重写过程中，主进程接收到写命令，写入到aof_buf后，然后判断此时是否正在执行重写 操作，如果是再将写命令写入 到AOF重写缓冲区，主进程返回
5. 当子进程完成对AOF文件重写之后，它会向父进程发送一个完成信号，父进程接到该完成信号之后，会调用一个信号处理函数，该函数完成以下工作：
     1）.将AOF重写缓存中的内容全部写入到新的AOF文件中；这个时候新的AOF文件所保存的数据库状态和服务器当前的数 据库状态一致；
     2）.对新的AOF文件进行改名，原子的覆盖原有的AOF文件；完成新旧两个AOF文件的替换。到这里才是一次完整的AOF重写流程
     3).当这个信号处理函数执行完毕之后，主进程就可以继续像往常一样接收命令请求了。在整个AOF后台重写过程中，只有最后的“主进程写入命令到AOF缓存”和“对新的AOF文件进行改名，覆盖原有的 AOF文件。”这两个步骤（信号处理函数执行期间）会造成主进程阻塞，在其他时候，AOF后台重写都不会对主进程造成阻塞，这将AOF重写对性能造成的影响降到最低。
 6. 如果AOF重写失败 redis会删除中间临时产物，保证流程的健壮性

详细内容，参考：深入浅出AOF功能和AOF重写两个知识点 - 简书

AOF持久化机制总结

AOF持久化机制的优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据.
• AOF日志文件通常以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，并且文件不容易破损，即使文件尾部破损，也很容易修复。
• AOF日志文件过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的日志进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
• AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据.

AOF持久化机制的缺点

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
• AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。