AOF 复写

AOF 复写

上一篇博客我们提到AOF持久化有一个缺点是，aof持久化的文件会越来越大，导致redis因为某个原因重启时需要加载的aof文件会非常大，加载的很缓慢，针对这一缺点就引入了AOF复写。

什么时AOF复写

Redis 为了避免 AOF 文件越写越大，提供了 AOF 重写机制，当 AOF 文件的大小超过所设定的阈值后，阈值是64M，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。

AOF 重写机制是在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。

重写工作完成后，就会将新的 AOF 文件覆盖现有的 AOF 文件，这就相当于压缩了 AOF 文件，使得 AOF 文件体积变小了。

为什么在复写AOF的时候，不直接在原有的AOF上复写，而是复写到新的文件取替换AOF文件？

因为如果 AOF 重写过程中失败了，现有的 AOF 文件就会造成污染，可能无法用于恢复使用。
所以 AOF 重写过程，先重写到新的 AOF 文件，重写失败的话，就直接删除这个文件就好，不会对现有的 AOF 文件造成影响。

AOF重写流程

读取redis数据库中的所有key-value 数据，用一条命令的方式写入新的日志文件中
但是由于读取的key-value数据过大，所以如果是放在主线程会阻塞业务逻辑的正常执行，一般复写的过程是放在后台进程执行。

触发重写机制后，主进程就会创建重写 AOF 的子进程，此时父子进程共享物理内存，重写子进程只会对这个内存进行只读，重写 AOF 子进程会读取数据库里的所有数据，并逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志（新的 AOF 文件）。

但是子进程重写过程中，主进程依然可以正常处理命令。

如果此时主进程修改了已经存在 key-value，就会发生写时复制，注意这里只会复制主进程修改的物理内存数据，没修改物理内存还是与子进程共享的。

所以如果这个阶段修改的是一个 bigkey，也就是数据量比较大的 key-value 的时候，这时复制的物理内存数据的过程就会比较耗时，有阻塞主进程的风险。

AOF重写由后台进程执行的好处

1. 避免阻塞主进程的正常执行
2. 如果是多线程需要加锁保证主线程和子线程的数据的安全性，如果是多进程，fork一个子进程后，操作系统会复制父进程的页表给子进程。相当于共享了物理空间，当父进程因为写入数据时，会发生写时复制的现象，依然能够保证数据的安全性。不用加锁保证数据的安全性。
   注意：写实复制在前面的博客中由讲解到，这里就不多讲解了。

重写 AOF 日志过程中，如果主进程修改了已经存在 key-value，此时这个 key-value 数据在子进程的内存数据就跟主进程的内存数据不一致了，这时要怎么办呢？

为了解决这种数据不一致问题，Redis 设置了一个 AOF 重写缓冲区，这个缓冲区在创建 bgrewriteaof 子进程之后开始使用。

在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 「AOF 缓冲区」和 「AOF 重写缓冲区」。

在 bgrewriteaof 子进程执行 AOF 重写期间，主进程需要执行以下三个工作:

• 执行客户端发来的命令；
• 将执行后的写命令追加到 「AOF 缓冲区」；
• 将执行后的写命令追加到 「AOF 重写缓冲区」；
  当子进程复写完数据后，会发送一个信号给主进程，这里的信号指的是进程间通信的信号。然后主进程进行一下操作
• 将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致；
• 新的 AOF 的文件进行改名，覆盖现有的 AOF 文件。

在整个 AOF 后台重写过程中，除了发生写时复制会对主进程造成阻塞，还有信号处理函数执行时也会对主进程造成阻塞，在其他时候，AOF 后台重写都不会阻塞主进程。