文章目录
- [缓冲AOF 策略(append only file)](#缓冲AOF 策略(append only file))
- [AOF 的工作流程](#AOF 的工作流程)
- [AOF 缓冲区策略](#AOF 缓冲区策略)
- [AOF 的重写机制](#AOF 的重写机制)
- 重写完的AOF文件为什么可以变小？
- [AOF 重写流程](#AOF 重写流程)
缓冲AOF 策略(append only file)
AOF 的核心思路是 "实时备份"，只要我添加了新的数据或者更新了新的数据，就立刻将数据备份到硬盘中。
在 Redis 的配置文件中，默认是将 AOF 这种方式关闭的，所以我们想要使用 AOF 时，就需要修改一下配置文件，如下图：
然后重启服务器，就会自动生成一个 aof 文件，aof 文件的位置和 rdb 文件的是一样的，都是在 /var/lib/redis 目录下
下面我们来设置几个键值对进行测试：
- 设置键值对
- 使用 kill -9 杀死redis进程
当这里杀死完 redis 进程后，由于 unbent 系统的保护措施，会自动再启动一个 redis 服务器
- 查看redis内存中的键值对是否进行了备份
从下图可以看到，aof 文件中，已经实时的自动帮我们进行了备份了，并且，也可以看到，这个 aof 文件是一个文本文件。
如果我们开启了 AOF，在 aof 文件中进行了备份，又通过 bgsave 命令在 rdb 文件中进行备份，那么在重启 redis 服务器后，它是会加载两个文件中的数据吗？？？
答案：并不是的，当我们开启了 AOF 后，rdb 文件就不会再使用了，这个文件就相当于是透明的了，接下来的备份操作以及读取数据都是在 aof 文件中进行的。
AOF 的工作流程
Redis 之所以速度很快，最主要的原因是因为：它是操作内存的。
但是，在引入了 AOF 之后，又要写内存，又要写硬盘，那么样不久大大拖慢了速度吗？？？
实际上，并没有什么太大的影响的，因为，AOF 机制并非是直接让工作线程把数据写入硬盘，而是先写入到一个内存缓冲区中(AOF缓冲区)，等到积累的一定量的数据之后，再把缓冲区的数据一次性写入到硬盘中，此时就大大降低了写硬盘的次数，在写硬盘的时候，写入数据的多少对于性能影响没有很大，但是写硬盘的次数则影响很大了！！！
通过上述的讲解，此时就又会出现一个问题，如果把数据写入到内存缓冲区里，本质上还是在内存里呀，如果万一掉电了或者进程挂了，此时数据不久丢失了吗？？？
答案：是的，这种情况下，数据确实就会丢失。而AOF 机制就给了我们一些选项，也就是缓冲区的刷新策略，让我们根据实际情况对 "效率" 和 "数据的可靠性" 作一个取舍。
当刷新频率越高时，性能影响就越大，同时数据的可靠性就越高。
刷新频率越低时，性能影响就越小，同时数据可靠性就降低了，数据就容易丢丢失。
就像mysql的隔离级别一样，想要提高隔离性，并发程度就降低了，想要提高并发程度，隔离性就降低了。
此时，就让我想起了苏轼的一句话，人有悲欢离合，月有阴晴圆缺，此事古难全。想要鱼和熊掌兼得，这是不容易的，
AOF 缓冲区策略
AOF 缓冲区的策略是在配置文件中由 appendsync 参数的值控制的，策略值都有以下几个：
| aways | 频率是最高的，数据的可靠性最高，性能最低 |
|---|---|
| everysec | 频率降低，数据的可靠性减低，性能得到提高 |
| no | 频率最低，数据的可靠性最低，性能最高 |
在配置文件中，默认的就是 everysec，如下图：
AOF 的重写机制
AOF 它的设定是将用户的每次操作都写入到 AOF 中，但是随着 redis 的持续运行，AOF 的文件就会越来越大，体积大了之后，就会影响到 redis 的下次启动时间，因为 redis 启动的时候，就要恢复数据，如果数据太多，就会影响启动时间，这是其一，其二就是 aof 文件中有一些内容是冗余的！！！
举个例子，如下图：
以上，这三次操作过程就可以转化成一次操作，所以这三次操作过程就是冗余的。
所以，针对 aof 文件过大的问题，就利用了重写机制给 aof 文件进行重写，就可以达到瘦身效果。
重写完的AOF文件为什么可以变小？
首先呢，在 redis 的 aof 文件中，记录的是整个操作过程，例如 lpush key 111 ，但是，redis 在启动的时候，并不关注这些过程，只是关注这些结果，也就是内存中都有哪些数据。
所以，就对 aof 文件进行整理 ，这个整理是能够剔除其中的冗余操作，并且合并一些操作，达到给 aof 文件瘦身这样的效果。就相当于中间的过程能去掉就去掉，只保留结果即可。
而且，在旧的 aof 文件中，也可能会存在像 del、hdel、srem这样的删除命令，但是经过这样的命令之后，数据都被删除了，而在aof文件中保留的这些删除操作也没啥用，所以也要进行清除掉，所以，重写完的 aof 文件就会变小。
AOF 重写流程
AOF 的重写也是分为以下两种：
① 手动触发：调用 bgrewriteaof 命令
② 自动触发：在配置文件中，根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。
- auto-aof-rewrite-min-size ：表示当文件达到多大时，就触发重写操作，默认位 64MB
- auto-aof-rewrite-percentage：表示当前 AOF 文件的大小相比较上次重写时的比例，比如，指定了这个比例是 50%，如果上次重写是的文件大小是 0.5g，当前文件大小是 1g，此时就会触发自动重写。
重写流程如下：
① 父进程通过fork创建出子进程，此时，父进程仍然负责接收客户端请求，子进程负责针对 aof 文件进行重写。
那么，这个重写是具体是如何重写的呢？？？
其实，重写的时候，并不关心 aof 文件中原来都有啥，只是关心内存中最终的数据状态，所以，在进行重写时，并不需要再去遍历旧的 aof 文件，把最终结果整理出来，因为，我们只需要获取到最终的数据即可，而最终的数据现在也就是在内存中保存着的呀，所以，子进程只需要把内存中当前的数据，获取出来，以 AOF 的格式写入到新的 aof 文件中即可。
此处的子进程写数据的过程，非常类似于 RDB 生成一个快照文件，只不过，RDB 这里是按照二进制的方式生成的，AOF 重写，则是按照 AOF 这里要求的文本格式来生成的。
② 子进程在重写的过程中呢，父进程也还仍然在不停的接收客户端发来的请求，此时，父进程还是会把这些请求产生的 AOF 数据先写入到"缓冲区"中，再刷新到旧的 AOF 文件中。
而且要注意，在创建子进程的一瞬间，它就相当于继承了当前父进程的内存状态，也就是当前父进程的内存中有啥，子进程的内存中就有啥（这里看起来父进程和子进程好像是同一块内存空间，其实是不同的内存空间，子进程是对父进程的内存空间进行了拷贝，只不过是按照写实拷贝的方式进行的）而子进程中只是包含了 fork 之前的内存数据，而 fork 之后，新来的请求对内存造成的修改，子进程是感知不到的。
③ 但是此时，父进程这里有准备了一个 aof_rewrite_buf，这里就会专门放 fork 之后收到的数据，所以，在 fork 之后，父进程不仅要向 aof_buf 缓冲区中写入数据，还要向 aof_rewrite_buf 缓冲区中写数据。aof_buf 缓冲区主要还是为了往旧的 aof 文件中写数据，而 aof_rewrite_buf 主要是为了后续往新的 aof 文件中写数据，等到子进程这边把数据重写完之后，就会通过"信号"通知一下父进程，父进程再把 aof_rewrite_buf 缓冲区中的数据也写入到新的 aof 文件中。这也就意味着，新的 aof 文件中的数据主要来自两方面，一个是 fork 之前的数据，一个是 fork之后的数据，等到父进程这里也写完之后，就可以用新的 aof 文件代替旧的 aof 文件了。
如果在执行 bgrewriteaof 的时候，当前的 redis 已经正在进行 aof 重写了，会怎么样呢？？？
也就是上一个重写操作还没完成，此时，就又来了个 bgrewriteaof 命令，此时，父进程会进行一个判定，如果此时正在重写，就不会再次执行 bgrewriteaof 命令了。
如果在执行 bgrewriteaof 的时候，发现当前 redis 在生成 rdb 快照文件时，会怎么样？？？
此时，aof 重写操作会等待，等到 rdb 快照生成完毕之后，再进行重写。
因为最后都是要写入到新的 aof 文件中，并且，新的 aof 文件最后也会替代旧的 aof 文件，那么，在fork之后，写入数据时，为啥还要再将数据写入到旧的 aof 文件中呢。不写旧的aof文件，直接将数据都交给子进程写新的aof文件不行吗？？？
为最后都是要写入到新的 aof 文件中，并且，新的 aof 文件最后也会替代旧的 aof 文件，那么，在fork之后，写入数据时，为啥还要再将数据写入到旧的 aof 文件中呢。不写旧的aof文件，直接将数据都交给子进程写新的aof文件不行吗？？？
答案是：不行，如果出现一种极端的情况，比如，子进程在重写的过程中，重写了一半了，服务器挂了，显然这样的重写就断了，子进程内存中的数据就丢失了，新的 aof 文件内容还不完整，此时，并且缓冲区中的数据也会烟消云散了，那么如果没有写旧的aof文件，那就凉凉喽~~