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

发布于 2022-4-9 23:18
浏览
0收藏

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

01、AOF介绍

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

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

 

redis灵魂拷问:聊一聊AOF日志重写-开源基础软件社区

 

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

当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重写是否会阻塞主线程呢?

AOF重写并不是在主线程中,而是redis会fork一个bgrewriteaof子进程,这样就不会阻塞主线程执行了。

fork子进程的过程是要在主线程中执行的,这时候主线程需要拷贝内存页表,这个页表记录了虚拟内存和物理内存的映射关系,如果内存很大,拷贝过程花费的时间就会很大,而这个拷贝过程中主线程是阻塞的。

fork子进程完成后,主线程和bgrewriteaof子进程使用的是同一块儿内存空间,这时如果有新的写请求到来,并且写命令是已经存在的key,主线程会使用CopyOnWrite的方式,为这个key申请新的内存空间,进行写操作。如果这个key是一个bigkey,那也会耗时很多。

下面我画了一个简单的图,主线程fork出bgrewriteaof子进程时,复制了一个页表给子进程用,跟自己指向相同的内存空间。但是AOF重写过程中收到了foo这个key的写命令,这时主线程需要拷贝一份数据到新的内存空间进行修改。redis灵魂拷问:聊一聊AOF日志重写-开源基础软件社区

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

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

本文转载自微信公众号「君哥聊技术」

原文链接:https://mp.weixin.qq.com/s/UtBYPwEJuyrIInUUYUvxXg。

分类
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐