Redis 2.4版本做了很多功能改进,尤其是aof这块变动较大。增加了自动的bgrewriteaof,开启两个后台线程来避免主线程fsync、rename、close等阻塞操作,另外修复了出现重复命令进入aof文件的bug,下面是基于2.4.1的源码aof这块的改进分析。
旧的版本问题主要有:
- 1 主线程aof的每次fsync(everysecond模式)在高并发下时常出现100ms的延时,这源于fsync必不可少的磁盘操作,即便已经优化多次请求的离散小io转化成一次大的连续io(sina的同学也反映过这个问题).
- 2 主线程里backgroundRewriteDoneHandler函数在处理bgrewriteaof后台进程退出的时候存在一个rename new-aof-file old-aof-file,然后再close old-aof-file的操作, close是一个unlink的操作(最后的引用计数), unlink消耗的时间取决于文件的大小,是个容易阻塞的系统调用.
- 3 当发生bgsave或者bgrewriteaof的时候主线程和子进程同时写入不同的文件,这改变了原有连续写模式,不同写入点造成了磁盘磁头的寻道时间加长(其实一个台物理机多实例也有这个问题, 要避免同一时间点做bgrewriteaof), 这又加长了fsync时间.
在2.4版里把fsync和close操作都移动到background来执行.
解决问题1
主线程仅仅把aofbuf的数据刷新到aof文件里,然后通过bioCreateBackgroundJob函数往这队列里插入fsync job,于是原有主线程的fsync工作被转移到后台线程来做,这样主线程阻塞问题就异步的解决了.
但这又引发了一个问题,主线程对同一个fd如果有write操作,后台线程同时在fsync,这两个线程会互相影响. a