redis的aof功能的目的是在性能和持久化粒度上对持久化机制提供更好的支持。 快照方式持久化的粒度有时间(秒)和改变的key数两种,如果持久化的粒度较小,对性能会有较大的影响,因为每次都是dump整个db;如果持久化的粒度较大,则在指定时间内指定数目的数
redis的aof功能的目的是在性能和持久化粒度上对持久化机制提供更好的支持。
快照方式持久化的粒度有时间(秒)和改变的key数两种,如果持久化的粒度较小,对性能会有较大的影响,因为每次都是dump整个db;如果持久化的粒度较大,则在指定时间内指定数目的数据的持久化无法保证。而aof持久化的粒度是每次会修改db数据的命令,因此粒度是最小的了,跟日志方式有点类似,由于仅记录一条命令,性能也最好。另外,跟日志类似,aof文件会越来越大,则可以通过执行bgrewriteaof命令在后台重建该文件。
我们先来看看redis如何记录命令的。
call函数是命令执行的函数(前面命令处理章节已详细介绍过该函数)。如果命令执行前后数据有修改,则server.dirty的取值会有变化。在启用了aof机制的情况下,call函数会调用feedappendonlyfile保存命令及其相关参数。
static void call(redisclient *c, struct rediscommand *cmd){ long long dirty; dirty = server.dirty; cmd->proc(c); dirty = server.dirty-dirty; if(server.appendonly && dirty) feedappendonlyfile(cmd,c->db->id,c->argv,c->argc); ---}
feedappendonlyfile会首先检查当前命令所处的db是否跟前一条命令执行所处db一致。若不一致,则需要发布一条选择db的select命令,然后做些命令的转换工作(代码略去)。
紧接着,将命令参数所对应的buf保存到server.aofbuf中,该参数保存了一段时间内redis执行的命令及其参数,redis会在适当的时机将其刷到磁盘上的aof文件中;然后如果有后台重建aof文件,则也将该缓冲区保存到server.bgrewritebuf中,该缓冲区保存了重建aof文件的后台进程运行时redis所执行的命令及其参数,后台进程退出时需要将这些命令保存到重建文件中。
static void feedappendonlyfile(struct rediscommand *cmd, int dictid, robj **argv, int argc){ --- server.aofbuf = sdscatlen(server.aofbuf,buf,sdslen(buf)); --- if(server.bgrewritechildpid != -1) server.bgrewritebuf = sdscatlen(server.bgrewritebuf,buf,sdslen(buf)); sdsfree(buf);}
我们来看看server.aofbuf会在什么时机被刷新到磁盘aof文件中。
刷新采用的是flushappendonlyfile函数。该函数在beforesleep中会被调用(事件处理章节已介绍过该函数),而该函数是在处理client事件之前执行执行的(事件循环函数aemain是先执行beforesleep,然后执行aeprocessevents),因此,server.aofbuf中的值会在向client发送响应之前刷新到磁盘上。
flushappendonlyfile调用write一次性写全部server.aofbuf缓冲区中的数据,并根据配置的同步策略,调用aof_fsync(对系统同步函数fsync的保证)进行同步,这样新的命令及其参数就被附加到aof文件当中了。
static void flushappendonlyfile(void){ time_t now; ssize_t nwritten; --- nwritten = write(server.appendfd,server.aofbuf,sdslen(server.aofbuf)); --- sdsfree(server.aofbuf); server.aofbuf = sdsempty(); /* fsync if needed */ now = time(null); if(server.appendfsync == appendfsync_always|| (server.appendfsync == appendfsync_everysec && now-server.lastfsync > 1)) { /* aof_fsync is defined as fdatasync() for linux in order to avoid * flushing metadata. */ aof_fsync(server.appendfd);/* let's try to get this data on the disk */ server.lastfsync = now; }}
接下来我们看看后台如何重建aof文件。
aof重建靠调用rewriteappendonlyfilebackground函数完成。查看该函数的调用关系就可以知道,该函数会在收到bgrewriteaof命令后执行,也会在收到config命令并且从不使用aof机制到开启aof机制时被调用,也会在运行redis的系统作为slave时,跟master建立连接后并在servercron函数中执行syncwithmaster时调用。
rewriteappendonlyfilebackground重建aof的主要逻辑如下(代码略去):
1)使用fork创建一个子进程
2)子进程调用rewriteappendonlyfile在一个临时文件里写能够反映当前db状态的数据和命令,
此时父进程会把这段时间内执行的能够改变当前db数据的命令放到server.bgrewritebuf中(参看前面对feedappendonlyfile的解释)
3)当子进程退出时,父进程收到信号,将上面的内存缓冲区中的数据flush到临时文件中,然后将临时文件rename成新的aof文件(backgroundrewritedonehandler)。
父进程会在servercron函数中等待执行aof重写或者快照保存的子进程,代码如下:
/* check if a background saving or aof rewrite in progress terminated */ if(server.bgsavechildpid != -1||server.bgrewritechildpid != -1){ int statloc; pid_t pid; if((pid = wait3(&statloc,wnohang,null))!= 0){ if(pid == server.bgsavechildpid){ backgroundsavedonehandler(statloc); } else { backgroundrewritedonehandler(statloc); } updatedictresizepolicy(); } }
rewriteappendonlyfile将反映当前db状态的命令和参数写到一个临时文件中。该函数遍历db中的每条数据,redis中的db其实是一个大的hash表,每一条数据都用(key,val)来表示。从key可以知道val的类型(redis支持redis_string、redis_list、redis_set、redis_zset、redis_hash五种数据类型),然后解码val中的数据。写入时,按照客户端执行命令的形式写入。比如对于redis_string类型,则先写入”*3\r\n$3\r \nset\r\n”,然后写入set的key,然后写入val;对于redis_list类型,将val强制转换为list类型后,先写入”*3\r \n$5\r\nrpush\r\n”,然后写入要操作的list的名字,然后写入list的第一个数据,循环前面3个步骤直到list遍历完;对于redis_set类型,则对于每条数据先写入”*3\r\n$4\r\nsadd\r\n”;对于redis_zset类型,则对于每条数据先写入”*4\r\n$4\r\nzadd\r\n”;对于redis_hash类型,则对于每条数据先写入”*4\r\n$4\r\nhset\r\n”(代码简单但较琐碎,略去)。
最后我们介绍下redis启动时使用aof重建db的步骤。
启动时重建的关键是构建一个fake client,然后使用这个client向server发送从aof文件中读入的命令。
int loadappendonlyfile(char *filename){ --- fakeclient = createfakeclient(); while(1){ --- if(fgets(buf,sizeof(buf),fp)== null){ --- } // 解析buf为对应的命令及参数 // 查找命令 cmd = lookupcommand(argv[0]->ptr); --- // 执行命令 cmd->proc(fakeclient); --- } ---}
原文地址:redis源代码分析18–持久化之aof, 感谢原作者分享。