Redis之AOF持久化
前面已经介绍过Redis的RDB持久化详情请看博客地址：https://blog.csdn.net/sinat_32366329/article/details/81160282
AOF持久化
Redis提供的RDB持久化是将数据以二进制存储到后缀为rdb的文件中，AOF持久化则是通过将所有的对数据库写入操作的命令存储到aof文件中实现持久化。
实现原理
AOF持久化功能的实现可以分为命令追加/文件写入/文件同步三个步骤。
命令追加
当AOF持久化功能处于开启状态的时候，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区中。
文件写入与同步
当命令追加到aof_buf缓冲区后，服务器就会调用flushAppendOnlyFile函数，根据配置的策略决定是否将aof_buf缓冲区中的内容写入和保存到AOF文件中。具体的策略如下：
| Always |
每次写操作完成都同步一次aof_buf数据到AOF文件 |
| everysec |
由线程负责，每秒同步一次aof_buf数据到AOF文件 |
| no |
什么时候同步aof_buf数据到AOF文件由操作系统控制 |
AOF文件的载入与数据还原
AOF持久化一旦开启，那么RDB持久化就失效。所以Redis在重启的时候，如果发现AOF持久化开启，就会读取AOF文件恢复数据状态，而忽略RDB文件。一开始就说过了AOF持久化是通过将数据库的写命令保存起来实现的，所以Redis只需要将AOF文件中的命令执行一遍就可以恢复数据库数据状态。
AOF重写
既然知道AOF是将写命令存储到AOF文件中实现持久化，那么就应该会想到AOF文件体积越来越大，一旦达到某个量级，重启Redis的时间必将严重增加。
为了解决这个问题，Redis提供了AOF文件重写功能。通过该功能，可以创建一个新的AOF文件替换现有的AOF文件，两个AOF文件的数据库数据一致，但是新的AOF文件不会包含浪费空间的冗余命令。而且提交会比旧的AOF文件小的多。
AOF重写实现原理
AOF文件重新并不需要对现有的AOF文件进行任何读取，分析或者写入操作，而是通过读取当前数据库的数据来完成的。简单总结就是：读取当前数据库中键现有的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。
AOF重写过程数据不一直
为什么会出现重写后AOF数据不一直的问题呢？我们可以这样思考：1）Redis后台进程处理AOF重写。2）对like={“1”, “2”,”3”}这个键值对完成了重写。3）用户对like这个键执行了删除3这个值。4）重写完成。这样导致的原因是在AOF重写过程中，有用户对数据库重新执行了写操作，导致重新的AOF文件不一直。
针对这个问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始调用，当Redis服务器执行完一个写命令后，它会同时将这个命令发送给AOF缓冲区和AOF重写缓冲区。在AOF重写完成后，会执行AOF重写缓冲区的命令确保数据库数据的一直性。