redis灵魂拷问：聊一聊AOF日志重写

“ AOF日志重写到底会不会阻塞主线程？”

01

—

AOF介绍

redis的AOF日志，是redis持久化的一种方式，它是一种write after log，即先执行命令后记录日志。这样的好处是日志不会记录执行失败的命令，同时记录日志不会阻塞当前命令执行。

记录AOF是在主线程中执行的，所以也会阻塞主线程。这个跟AOF的写回策略有关，这个配置项参数叫appendfsync，在redis.conf文件中，默认值是everysec。下面是3种写回策略的比较：

这样，我们就需要在性能和可靠性之间做一些取舍了。

当redis上执行的命令越来越多，AOF日志文件会变得很大，这样AOF文件追加命令会很慢，而且操作系统对文件大小也有一定的限制，再者如果使用AOF做主从同步或数据恢复的话，因为命令记录太多会导致耗时很长。redis解决这个问题的手段就是AOF日志重写。

02

—

AOF重写介绍

在redis.conf文件中，有下面2个参数来控制AOF重写：

auto-aof-rewrite-percentage 100 #AOF文件大小较上次重写超过100%时进行重写
auto-aof-rewrite-min-size 64mb #aof文件大小超过64m时重写

下面我们执行6条命令：

192.168.59.146:6379> set name jinjnzhu
OK
192.168.59.146:6379> set password 123456
OK
192.168.59.146:6379> set name jinjunzhu1
OK
192.168.59.146:6379> set password 1234567
OK
192.168.59.146:6379> set name jinjunzhu2
OK
192.168.59.146:6379> set password 12345678
OK

之后我们查看name和password的值：

192.168.59.146:6379> get name
"jinjunzhu2"
192.168.59.146:6379> get password
"12345678"

这2个key的值被赋予了最新的一次赋值，虽然我们执行了6条命令，但是AOF重写后日志文件就剩了最后2条命令。

03

—

AOF重写对性能的影响

在上小节的介绍中，如果AOF文件较上次重写超过了100%，就要进行重写。但是如果日志特别大，AOF重写后把日志写回磁盘也是一个非常耗时的操作，那么AOF重写是否会阻塞主线程呢？

1. AOF重写并不是在主线程中，而是redis会fork一个bgrewriteaof子进程，这样就不会阻塞主线程执行了。
   
2. fork子进程的过程是要在主线程中执行的，这时候主线程需要拷贝内存页表，这个页表记录了虚拟内存和物理内存的映射关系，如果内存很大，拷贝过程花费的时间就会很大，而这个拷贝过程中主线程是阻塞的。
   
3. fork子进程完成后，主线程和bgrewriteaof子进程使用的是同一块儿内存空间，这时如果有新的写请求到来，并且写命令是已经存在的key，主线程会使用CopyOnWrite的方式，为这个key申请新的内存空间，进行写操作。如果这个key是一个bigkey，那也会耗时很多。
   

下面我画了一个简单的图，主线程fork出bgrewriteaof子进程时，复制了一个页表给子进程用，跟自己指向相同的内存空间。但是AOF重写过程中收到了foo这个key的写命令，这时主线程需要拷贝一份数据到新的内存空间进行修改。

在AOF重写的过程中，如果有新的写命令到来了，会影响AOF重写吗？

当然不会，新的写命令不仅会记录到AOF日志的缓存区，还会记录到重写的新AOF日志缓存区，这样当AOF重写结束后，把重新缓存区数据写到新AOF文件，就不会丢失了。