在学习AOF原理前,我们首先要了解 RESP (Redis的序列化协议)
从图中可以看到客户端在调用redis服务端时,传入的命令和 key、value 都会通过 RESP 协议序列化为文本。AOF文件中存储的就是序列化后的reids命令。
AOF同步和RDB类似之处在于都是采用fork进程来处理:
通过这张图,我们知道了Redis是将客户端传入的命令直接写入AOF文件的,那如果同一个key原本值是0,然后改为1,最后在改为2,如果每一条命令都记录不仅毫无意义,同时会使得AOF文件越来越大,所以 Redis 在这块有一个小优化。
set s1 11
set s1 22
上面的操作,如果没有优化之前AOF文件是会将这两个命令按照RESP序列化后存储,如果优化后,则只存储后面一条命令即 set s1 22,同一个key的值被覆盖了,只存储最终结果。
重写过程分析
那如果做到同一个key在AOF文件中只存储最新的值呢?不可能每一次写入文件前去检查一遍删除之前这个key的值吧,这样做效率肯定贼低,我们来看看Redis是怎么做的?
Redis 其实是会定期新创建一个 AOF 文件,然后做 AOF 文件的重写优化,在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕, Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
这个操作不得不说还是玩的66的!大写的服。
优化的触发条件:
那上面说的定期重建 AOF 文件具体的时机是啥时候呢?答案也在配置文件 redis.conf 中,需要如下的配置即可,我已经写了注释,你一眼就能看懂的。
# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过,以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小,也就是文件大小小于64mb的时候,不需要进行优化
auto-aof-rewrite-min-size 64mb
全部0条评论
快来发表一下你的评论吧 !