浅谈 AOF 重写机制

概述

AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的信息一样，但体积更小，可以节省 Redis 的空间。

AOF重写之所以有日志瘦身的作用，原因在于其可以将旧日志文件中的多条命令，在重写后的新日志中变成一条命令。比如对一个list里面的元素写了又删，我就可以合并为一条命令 → LPUSH A B C D…。

为什么需要AOF重写

如果不进行AOF重写，会导致AOF文件越来越大，从而产生性能问题：

1. 文件系统本身对文件大小有限制，无法保存过大的文件。
2. 如果文件太大，之后再往里面追加命令记录的话，效率也会变低。
3. 如果发生宕机，AOF中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，影响到 Redis 的正常使用。

AOF重写流程

AOF重写不会阻塞主线程，其重写过程是由后台子进程 bgrewriteaof 来完成的，从而避免了性能下降。
具体流程如下：

1. 把主线程的内存拷贝一份给fork出来的 bgrewriteaof 子进程，这里面包含了Redis中最新的数据。
2. 子进程将其中的数据进行重写。
3. 主线程维护一个AOF缓冲区（实际上无论重不重写都有这个缓冲区，因为AOF日志写入是 → AOF缓冲区 → AOF文件），如果此时有写操作，则会写入到AOF缓冲区以及AOF日志中，保证数据完整。
4. 主线程在重写时维护一个AOF重写缓冲区，将重写过程中的写操作记入其中，保证重写后的AOF日志也能记录在重写过程中产生的新数据。
5. 用新AOF替换老AOF日志。

思考：为什么AOF重写不采用覆盖的方式

1. 父子进程写同一个文件必然会产生竞争，如果控制竞争就意味着会影响父进程的性能。
2. 如果AOF重写失败，那么原本的AOF文件相当于被污染了，就直接废了。而采用覆盖的方式则不会有这种负面影响(重写失败就直接删了，一点影响没有)。

参考：蒋德钧老师《Redis核心技术与实战》极客时间专栏，强烈推荐！