Redis持久化（2）

书接上回，上一篇讲了用RDB来实现持久化，这次讲一下AOF是如何实现持久化的。

AOF

AOF就是append only file,类似于mysql的binlog，把用户的每个操作，记录到文件中去。且启动aof的时候，rdb就不生效了，启动时不再读取rdb的文件内容。

aof默认时关闭状态，可以修改配置文件来开启aof功能

红色的是aof文件名，所在目录跟rdb一样 /var/lib/redis 

aof是一个文本文件，每次进行操作都会被记录到文本文件中~

使用AOF

AOF的工作流程图

 都知道redis相比于mysql最大的优点就是速度快，但引入aof之后又要写内存，又要写硬盘，还能和之前一样快吗？

其实是不影响redis处理请求的速度的：

1. aof机制不是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区，积累一定数据之后，再统一写入硬盘中
2. 硬盘上读写数据，顺序读写的速度是比较快的(还是比内存要慢很多)，但随机访问速度是比较慢的~~

文件同步

如果把数据写入缓冲区里，但本质还是在内存中，如果进程挂了/主机掉电了，那么缓冲区中没来得及写入硬盘的数据就会丢失。

但没有事情是完美的！！！不能既要也要，要学会取舍~

redis就给出了一些选项，让我们根据实际情况来取舍，即缓冲区刷新策略！

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

 重写机制

aof文件持续增长，会影响到redis下次启动的启动时间。因为aof文件是有一些内容时冗余的。

redis启动的时候要读取aof文件的内容，aof文件记录了中间的过程，但redis重新启动时只关注最终结果。

因此redis就存在一个机制，能够针对aof文件进行整理操作，这个操作能够剔除其中的冗余操作，并合并一些操作，达到给aof”瘦身”的效果，就是重写机制~

 

aof重写流程

 

 在这个流程中有几点需要注意：

1. 创建子进程fork，父进程仍然负责接收请求，子进程负责针对aof文件进行重写。特别一点(重写的时候不关心aof文件原来都有啥，只关心内存中最终的数据状态)；子进程只需要把内存中当前的数据获取出来，以aof的格式写入到一个新的aof文件中！
2. 子进程写新的aof文件的同时，父进程仍然在不停的接收客户端新的请求，父进程还是会把这些请求产生的aof数据先写入到缓冲区中，再刷新到原有的aof文件里~
3. 因为创建子进程的一瞬间，子进程就继承了当前父进程的内存状态；因此子进程里的内存数据时父进程fork之前的状态，新来的请求对内存的修改子进程是不知道的；                            此时，父进程又准备了一个aof_rewrite_buf缓冲区，专门放fork之后收到的数据；                  子进程把aof数据写完之后，会通过“信号”通知一下父进程，父进程再把aof_rewrite_buf中的内容也写入到新的aof文件里~；  这时就能用新的aof文件代替旧的aof文件了~

AOF重写的特殊情况

• 如果在执行bgrewriteaof的时候，当前redis已经正在进行aof重写了，会怎么样？

         此时不会再次执行aof重写，直接返回了。

• 如果在执行bgrewriteaof的时候，发现当前redis在生成rdb文件的快照，会怎么样？

         此时aof重写操作就会等待，等待rdb快照生成完毕之后在执行aof重写。

• 父进程fork完毕之后，就已经让子进程写新的aof文件了，并且随着时间的推移，子进程很快就写完了新的文件，要让新的aof文件代替旧的~    父进程此时还继续写这个快消亡的旧的aof文件与偶没有意义？

         这是有意义的，因为有种极端情况，重写的过程中，重写一半服务器挂了，子进程的内存数           据就会丢失，新的aof文件内容还不完整，所以如果父进程不坚持写旧的aof文件，就没法保           证数据的完整性了~~

混合持久化

aof本来是按照文件的方式写入文件，但这种方式的后续加载成本是比较高的，所以redis就引入了“混合持久化的方式”(结合了rdb和aof的特点)。

比如在触发aof重写之后，就会把当前内存状态按照rdb的二进制格式写入道新的aof文件中，后续再进行的操作，仍然是按照aof文本的方式追加到文件后面~

可以看到，redis上同时存在aof文件和rdb快照时，是以aof为主的(aof中包含的数据比rdb更全)。 

以上就是redis持久化的内容，虽然内容较多，但并不难理解~