作者：朱鹏举

新人 DBA ，会点 MySQL ，Redis ，Oracle ，在常识的陆地中挣扎，活下来就算胜利...

本文起源：原创投稿

*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

AOF 作为 Redis 的数据长久化形式之一，通过追加写的形式将 Redis 服务器所执行的写命令写入到 AOF 日志中来记录数据库的状态。但当一个键值对被多条写命令重复批改时，AOF 日志会记录相应的所有命令，这也就意味着 AOF 日志中存在反复的"有效命令"，造成的后果就是 AOF 日志文件越来越大，应用 AOF 日志来进行数据恢复所需的工夫越来越长。为了解决这个问题，Redis 推出了 AOF 重写性能

什么是 AOF 重写

简略来说，AOF 重写就是依据过后键值对的最新状态，为它生成对应的写入命令，而后写入到长期 AOF 日志中。在重写期间 Redis 会将产生更改的数据写入到重写缓冲区 aof_rewrite_buf_blocks 中，于重写完结后合并到长期 AOF 日志中，最初应用长期 AOF 日志替换原来的 AOF 日志。当然，为了防止阻塞主线程，Redis 会 fork 一个过程来执行 AOF 重写操作。

如何定义 AOF 重写缓冲区

我晓得你很急，然而你先别急，在理解AOF重写流程之前你会先遇到第一个问题，那就是如何定义AOF重写缓冲区。

一般来说咱们会想到用malloc函数来初始化一块内存用于保留AOF重写期间主过程收到的命令，当残余空间有余时再用realloc函数对其进行扩容。然而Redis并没有这么做，Redis定义了一个aofrwblock构造体，其中蕴含了一个10MB大小的字符数组，当做一个数据块，负责记录AOF重写期间主过程收到的命令，而后应用aof_rewrite_buf_blocks列表将这些数据块连接起来，每次调配一个aofrwblock数据块。

//AOF重写缓冲区大小为10MB，每一次调配一个aofrwblocktypedef struct aofrwblock {unsigned long used, free;char buf[AOF_RW_BUF_BLOCK_SIZE]; //10MB} aofrwblock;

那么问题来了，为什么 Redis 的开发者要抉择本人保护一个字符数组呢，答案是在应用 realloc 函数进行扩容的时候，如果此时客户端的写申请波及到正在长久化的数据，那么就会触发 Linux 内核的大页机制，造成不必要的内存空间节约，并且申请内存的工夫变长。

Linux 内核从2.6.38开始反对大页机制,该机制反对2MB大小的內存页调配,而惯例的内存页调配是按4KB的粒度来执行的。这也就意味着在 AOF 重写期间，客户端的写申请可能会批改正在进行长久化的数据，在这一过程中, Redis 就会采纳写时复制机制，一旦有数据要被批改, Redis 并不会间接批改內存中的数据，而是将这些数据拷贝一份，而后再进行批改。即便客户端申请只批改100B的数据, Redis 也须要拷贝2MB的大页。

AOF 重写流程

不晓得说什么，贴个代码先。

int rewriteAppendOnlyFileBackground(void) {pid_t childpid;long long start;if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;if (aofCreatePipes() != C_OK) return C_ERR;openChildInfoPipe();start = ustime();if ((childpid = fork()) == 0) {char tmpfile[256];/* Child */closeListeningSockets(0);redisSetProcTitle("redis-aof-rewrite");snprintf(tmpfile,256,"temp-rewriteaof-bg-%d.aof", (int) getpid());if (rewriteAppendOnlyFile(tmpfile) == C_OK) {size_t private_dirty = zmalloc_get_private_dirty(-1);if (private_dirty) {serverLog(LL_NOTICE,"AOF rewrite: %zu MB of memory used by copy-on-write",private_dirty/(1024*1024));}server.child_info_data.cow_size = private_dirty;sendChildInfo(CHILD_INFO_TYPE_AOF);exitFromChild(0);} else {exitFromChild(1);}} else {/* Parent */server.stat_fork_time = ustime()-start;/* GB per second. */server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024);latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);if (childpid == -1) {closeChildInfoPipe();serverLog(LL_WARNING,"Can't rewrite append only file in background: fork: %s",strerror(errno));aofClosePipes();return C_ERR;}serverLog(LL_NOTICE,"Background append only file rewriting started by pid %d",childpid);server.aof_rewrite_scheduled = 0;server.aof_rewrite_time_start = time(NULL);server.aof_child_pid = childpid;updateDictResizePolicy();server.aof_selected_db = -1;replicationScriptCacheFlush();return C_OK;}return C_OK; /* unreached */}

一步到"胃"间接看源码置信不少同学都感觉很胃疼，然而整顿过后了解起来就会轻松不少

  • 父过程
  1. 若以后有正在进行的AOF重写子过程或者RDB长久化子过程，则退出AOF重写流程
  2. 创立3个管道
  3. parent -> children data
  4. children -> parent ack
  5. parent -> children ack
  6. 将parent -> children data设置为非阻塞
  7. 在children -> parent ack上注册读事件的监听
  8. 将数组fds中的六个⽂件描述符别离复制给server变量的成员变量
  9. 关上children->parent ack通道，用于将RDB/AOF保留过程的信息发送给父过程
  10. 用start变量记录以后工夫
  11. fork出一个子过程，通过写时复制的模式共享主线程的所有内存数据
  • 子过程
  • 敞开监听socket，防止接管客户端连贯
  • 设置过程名
  • 生成AOF长期文件名
  • 遍历每个数据库的每个键值对，以插入（命令+键值对）的形式写到长期AOF⽂件中
  • 父过程
  • 计算上一次fork曾经破费的工夫
  • 计算每秒写了多少GB内容
  • 判断上一次fork是否完结，没完结则此次AOF重写流程就此停止
  • 将aof_rewrite_scheduled设置为0（示意当初没有待调度执⾏的AOF重写操作）
  • 敞开rehash性能（Rehash会带来较多的数据挪动操作，这就意味着⽗过程中的内存批改会⽐较多，对于AOF重写⼦过程来说，就须要更多的工夫来执行写时复制，进⽽实现AOF⽂件的写⼊，这就会给Redis零碎的性能造成负⾯影响）
  • 将aof_selected_db设置为-1（以强制在下一次调用feedAppendOnlyFile函数（写AOF日志）的时候将AOF重写期间累计的内容合并到AOF日志中）

  • 当发现正在进行AOF重写工作的时候

    （1）将收到的新的写命令缓存在aofrwblock中

    （2）查看parent -> children data下面有没有写监听，没有的话注册一个

    （3）触发写监听时从aof_rewrite_buf_blocks列表中一一取出aofrwblock数据块，通过parent -> children data发送到AOF重写子过程

  • 子过程重写完结后，将重写期间aof_rewrite_buf_blocks列表中没有生产实现的数据追加写入到长期AOF文件中

管道机制

Redis创立了3个管道用于AOF重写时父子过程之间的数据传输，那么管道之间的通信机制就成为了咱们须要理解的内容。

1.子过程从parent -> children data读取数据 (触发机会)

  • rewriteAppendOnlyFileRio

    由重写⼦过程执⾏，负责遍历Redis每个数据库，⽣成AOF重写⽇志，在这个过程中，会不断地调⽤ aofReadDiffFromParent

  • rewriteAppendOnlyFile

    重写⽇志的主体函数，也是由重写⼦过程执⾏的，本⾝会调⽤rewriteAppendOnlyFileRio，调⽤完后会调⽤ aofReadDiffFromParent 屡次，尽可能多地读取主过程在重写⽇志期间收到的操作命令

  • rdbSaveRio

    创立RDB⽂件的主体函数，使⽤AOF和RDB混合长久化机制时，这个函数会调⽤aofReadDiffFromParent

//将从父级累积的差别读取到缓冲区中，该缓冲区在重写完结时连贯ssize_t aofReadDiffFromParent(void) {char buf[65536]; //大多数Linux零碎上的默认管道缓冲区大小ssize_t nread, total = 0;while ((nread =read(server.aof_pipe_read_data_from_parent,buf,sizeof(buf))) > 0) {server.aof_child_diff = sdscatlen(server.aof_child_diff,buf,nread);total += nread;}return total;}

2.子过程向children -> parent ack发送ACK信号

  • 在实现⽇志重写，以及屡次向⽗过程读取操作命令后，向children -> parent ack发送"!"，也就是向主过程发送ACK信号，让主过程停⽌发送收到的新写操作
int rewriteAppendOnlyFile(char *filename) {rio aof;FILE *fp;char tmpfile[256];char byte;//留神，与rewriteAppendOnlyFileBackground（）函数应用的长期名称相比，咱们必须在此处应用不同的临时名称snprintf(tmpfile,256,"temp-rewriteaof-%d.aof", (int) getpid());fp = fopen(tmpfile,"w");if (!fp) {serverLog(LL_WARNING,"Opening the temp file for AOF rewrite in rewriteAppendOnlyFile(): %s", strerror(errno));return C_ERR;}server.aof_child_diff = sdsempty();rioInitWithFile(&aof,fp);if (server.aof_rewrite_incremental_fsync)rioSetAutoSync(&aof,REDIS_AUTOSYNC_BYTES);if (server.aof_use_rdb_preamble) {int error;if (rdbSaveRio(&aof,&error,RDB_SAVE_AOF_PREAMBLE,NULL) == C_ERR) {errno = error;goto werr;}} else {if (rewriteAppendOnlyFileRio(&aof) == C_ERR) goto werr;}//当父过程仍在发送数据时，在此处执行初始的慢速fsync，以便使下一个最终的fsync更快if (fflush(fp) == EOF) goto werr;if (fsync(fileno(fp)) == -1) goto werr;//再读几次，从父级获取更多数据。咱们不能永远读取（服务器从客户端接收数据的速度可能快于它向子过程发送数据的速度），所以咱们尝试在循环中读取更多的数据，只有有更多的数据呈现。如果看起来咱们在浪费时间，咱们会停止（在没有新数据的状况下，这会在20ms后产生）。int nodata = 0;mstime_t start = mstime();while(mstime()-start < 1000 && nodata < 20) {if (aeWait(server.aof_pipe_read_data_from_parent, AE_READABLE, 1) <= 0){nodata++;continue;}nodata = 0; /* Start counting from zero, we stop on N *contiguous*timeouts. */aofReadDiffFromParent();}//发送ACK信息让父过程进行发送音讯if (write(server.aof_pipe_write_ack_to_parent,"!",1) != 1) goto werr;if (anetNonBlock(NULL,server.aof_pipe_read_ack_from_parent) != ANET_OK)goto werr;//期待父过程返回的ACK信息，超时工夫为10秒。通常父过程应该尽快回复，但万一失去回复，则确信子过程最终会被终止。if (syncRead(server.aof_pipe_read_ack_from_parent,&byte,1,5000) != 1 ||byte != '!') goto werr;serverLog(LL_NOTICE,"Parent agreed to stop sending diffs. Finalizing AOF...");//如果存在最终差别数据，那么将读取aofReadDiffFromParent();//将收到的差别数据写入文件serverLog(LL_NOTICE,"Concatenating %.2f MB of AOF diff received from parent.",(double) sdslen(server.aof_child_diff) / (1024*1024));if (rioWrite(&aof,server.aof_child_diff,sdslen(server.aof_child_diff)) == 0)goto werr;//确保数据不会保留在操作系统的输入缓冲区中if (fflush(fp) == EOF) goto werr;if (fsync(fileno(fp)) == -1) goto werr;if (fclose(fp) == EOF) goto werr;//应用RENAME确保仅当生成DB文件失常时，才主动更改DB文件if (rename(tmpfile,filename) == -1) {serverLog(LL_WARNING,"Error moving temp append only file on the final destination: %s", strerror(errno));unlink(tmpfile);return C_ERR;}serverLog(LL_NOTICE,"SYNC append only file rewrite performed");return C_OK;werr:serverLog(LL_WARNING,"Write error writing append only file on disk: %s", strerror(errno));fclose(fp);unlink(tmpfile);return C_ERR;}

3.父过程从children -> parent ack读取ACK

  • 当children -> parent ack上有了数据，就会触发之前注册的读监听
  • 判断这个数据是不是"!"
  • 是就向parent -> children ack写入"!"，表⽰主过程曾经收到重写⼦过程发送的ACK信息，同时给重写⼦过程回复⼀个ACK信息
void aofChildPipeReadable(aeEventLoop *el, int fd, void *privdata, int mask) {char byte;UNUSED(el);UNUSED(privdata);UNUSED(mask);if (read(fd,&byte,1) == 1 && byte == '!') {serverLog(LL_NOTICE,"AOF rewrite child asks to stop sending diffs.");server.aof_stop_sending_diff = 1;if (write(server.aof_pipe_write_ack_to_child,"!",1) != 1) {//如果咱们无奈发送ack，请告诉用户，但不要重试，因为在另一侧，如果内核无奈缓冲咱们的写入，或者子级已终止，则子级将应用超时serverLog(LL_WARNING,"Can't send ACK to AOF child: %s",strerror(errno));}}//删除处理程序，因为在重写期间只能调用一次aeDeleteFileEvent(server.el,server.aof_pipe_read_ack_from_child,AE_READABLE);}

什么时候触发AOF重写

开启AOF重写性能当前Redis会主动触发重写，破费精力去理解触发机制感觉意义不大。想法很不错，下次别想了。不然当你手动
执行Bgrewriteaof命令却发现总是报错时，疼的不只有你的头，还有你的胃。

1.手动触发
  • 以后没有正在执⾏AOF重写的⼦过程
  • 以后没有正在执⾏创立RDB的⼦过程，有会将aof_rewrite_scheduled设置为1（AOF重写操作被设置为了待调度执⾏）
void bgrewriteaofCommand(client *c) {if (server.aof_child_pid != -1) {addReplyError(c,"Background append only file rewriting already in progress");} else if (server.rdb_child_pid != -1) {server.aof_rewrite_scheduled = 1;addReplyStatus(c,"Background append only file rewriting scheduled");} else if (rewriteAppendOnlyFileBackground() == C_OK) {addReplyStatus(c,"Background append only file rewriting started");} else {addReply(c,shared.err);   }}
2.开启AOF与主从复制
  • 开启AOF性能当前，执行一次AOF重写
  • 主从节点在进⾏复制时，如果从节点的AOF选项被关上，那么在加载解析RDB⽂件时，AOF选项会被敞开，⽆论从节点是否胜利加载RDB⽂件，restartAOFAfterSYNC函数都会被调⽤，⽤来复原被敞开的AOF性能，在这个过程中会执行一次AOF重写
int startAppendOnly(void) {    char cwd[MAXPATHLEN]; //谬误音讯的当前工作目录门路    int newfd;    newfd = open(server.aof_filename,O_WRONLY|O_APPEND|O_CREAT,0644);    serverAssert(server.aof_state == AOF_OFF);    if (newfd == -1) {        char *cwdp = getcwd(cwd,MAXPATHLEN);        serverLog(LL_WARNING,            "Redis needs to enable the AOF but can't open the "            "append only file %s (in server root dir %s): %s",            server.aof_filename,            cwdp ? cwdp : "unknown",            strerror(errno));        return C_ERR;    }    if (server.rdb_child_pid != -1) {        server.aof_rewrite_scheduled = 1;        serverLog(LL_WARNING,"AOF was enabled but there is already a child process saving an RDB file on disk. An AOF background was scheduled to start when possible.");    } else {        //敞开正在进行的AOF重写过程，并启动一个新的AOF：旧的AOF无奈重用，因为它没有累积AOF缓冲区。        if (server.aof_child_pid != -1) {            serverLog(LL_WARNING,"AOF was enabled but there is already an AOF rewriting in background. Stopping background AOF and starting a rewrite now.");            killAppendOnlyChild();        }        if (rewriteAppendOnlyFileBackground() == C_ERR) {            close(newfd);            serverLog(LL_WARNING,"Redis needs to enable the AOF but can't trigger a background AOF rewrite operation. Check the above logs for more info about the error.");            return C_ERR;        }    }    //咱们正确地关上了AOF，当初期待重写实现，以便将数据附加到磁盘上    server.aof_state = AOF_WAIT_REWRITE;    server.aof_last_fsync = server.unixtime;    server.aof_fd = newfd;    return C_OK;}
3.定时工作
  1. 每100毫秒触发一次，由server.hz管制，默认10
  2. 以后没有在执⾏的RDB⼦过程 && AOF重写⼦过程 && aof_rewrite_scheduled=1

  3. 以后没有在执⾏的RDB⼦过程 && AOF重写⼦过程 && aof_rewrite_scheduled=0

    AOF性能已启⽤ && AOF⽂件⼤⼩⽐例超出auto-aof-rewrite-percentage && AOF⽂件⼤⼩绝对值超出auto-aofrewrite-min-size

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {......//判断以后没有在执⾏的RDB⼦过程 && AOF重写⼦过程 && aof_rewrite_scheduled=1if (server.rdb_child_pid == -1 && server.aof_child_pid == -1 &&server.aof_rewrite_scheduled){rewriteAppendOnlyFileBackground();}//查看正在进行的后盾保留或AOF重写是否终止if (server.rdb_child_pid != -1 || server.aof_child_pid != -1 ||ldbPendingChildren()){int statloc;pid_t pid;if ((pid = wait3(&statloc,WNOHANG,NULL)) != 0) {int exitcode = WEXITSTATUS(statloc);int bysignal = 0;if (WIFSIGNALED(statloc)) bysignal = WTERMSIG(statloc);if (pid == -1) {serverLog(LL_WARNING,"wait3() returned an error: %s.""rdb_child_pid = %d, aof_child_pid = %d",strerror(errno),(int) server.rdb_child_pid,(int) server.aof_child_pid);} else if (pid == server.rdb_child_pid) {backgroundSaveDoneHandler(exitcode,bysignal);if (!bysignal && exitcode == 0) receiveChildInfo();} else if (pid == server.aof_child_pid) {backgroundRewriteDoneHandler(exitcode,bysignal);if (!bysignal && exitcode == 0) receiveChildInfo();} else {if (!ldbRemoveChild(pid)) {serverLog(LL_WARNING,"Warning, detected child with unmatched pid: %ld",(long)pid);}}updateDictResizePolicy();closeChildInfoPipe();}} else {//如果没有正在进行的后盾save/rewrite，请查看是否必须立刻save/rewritefor (j = 0; j < server.saveparamslen; j++) {struct saveparam *sp = server.saveparams+j;//如果咱们达到了给定的更改量、给定的秒数，并且最新的bgsave胜利，或者如果产生谬误，至多曾经过了CONFIG_bgsave_RETRY_DELAY秒，则保留。if (server.dirty >= sp->changes &&server.unixtime-server.lastsave > sp->seconds &&(server.unixtime-server.lastbgsave_try >CONFIG_BGSAVE_RETRY_DELAY ||server.lastbgsave_status == C_OK))      {serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...",sp->changes, (int)sp->seconds);rdbSaveInfo rsi, *rsiptr;rsiptr = rdbPopulateSaveInfo(&rsi);rdbSaveBackground(server.rdb_filename,rsiptr);break;}}//判断AOF性能已启⽤ && AOF⽂件⼤⼩⽐例超出auto-aof-rewrite-percentage && AOF⽂件⼤⼩相对值超出auto-aof-rewrite-min-sizeif (server.aof_state == AOF_ON &&server.rdb_child_pid == -1 &&server.aof_child_pid == -1 &&server.aof_rewrite_perc &&server.aof_current_size > server.aof_rewrite_min_size){long long base = server.aof_rewrite_base_size ?server.aof_rewrite_base_size : 1;long long growth = (server.aof_current_size*100/base) - 100;if (growth >= server.aof_rewrite_perc) {serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);rewriteAppendOnlyFileBackground();}}}......return 1000/server.hz;}

AOF重写性能的毛病

哪怕是你心中的她，也并非是白璧无瑕的存在，更别说Redis这个人工产物了。但不去发现也就自然而然不存在毛病，对吧~

1.内存开销
  • 在AOF重写期间，主过程会将fork之后的数据变动写进aof_rewrite_buf与aof_buf中，其内容绝大部分是反复的，在高流量写入的场景下两者耗费的空间简直一样大。
  • AOF重写带来的内存开销有可能导致Redis内存忽然达到maxmemory限度，甚至会触发操作系统限度被OOM Killer杀死，导致Redis不可服务。
2.CPU开销
  • 在AOF重写期间主过程须要破费CPU工夫向aof_rewrite_buf写数据，并应用eventloop事件循环向子过程发送aof_rewrite_buf中的数据。
//将数据附加到AOF重写缓冲区，如果须要，调配新的块void aofRewriteBufferAppend(unsigned char *s, unsigned long len) {......//创立事件以便向子过程发送数据if (!server.aof_stop_sending_diff &&aeGetFileEvents(server.el,server.aof_pipe_write_data_to_child) == 0){aeCreateFileEvent(server.el, server.aof_pipe_write_data_to_child,AE_WRITABLE, aofChildWriteDiffData, NULL); }  ......}
  • 在子过程执行AOF重写操作的前期，会循环读取pipe中主过程发送来的增量数据，而后追加写入到长期AOF文件。
int rewriteAppendOnlyFile(char *filename) {......//再次读取几次以从父过程获取更多数据。咱们不能永远读取（服务器从客户端接收数据的速度可能快于它向子级发送数据的速度），因而咱们尝试在循环中读取更多数据，只有有很好的机会会有更多数据。如果看起来咱们在浪费时间，咱们会停止（在没有新数据的状况下，这会在20ms后产生）int nodata = 0;mstime_t start = mstime();while(mstime()-start < 1000 && nodata < 20) {if (aeWait(server.aof_pipe_read_data_from_parent, AE_READABLE, 1) <= 0){nodata++;continue;}nodata = 0; /* Start counting from zero, we stop on N *contiguous*timeouts. */aofReadDiffFromParent(); } ......}

在子过程实现AOF重写操作后，主过程会在backgroundRewriteDoneHandler中进行收尾工作，其中一个工作就是将在重
写期间aof_rewrite_buf中没有生产实现的数据写入长期AOF文件，耗费的CPU工夫与aof_rewrite_buf中遗留的数据量成正
比。

3.磁盘IO开销

在AOF重写期间，主过程会将fork之后的数据变动写进aof_rewrite_buf与aof_buf中，在业务顶峰期间其内容绝大部分是反复的，一次操作产生了两次IO开销。

4.Fork

虽说 AOF 重写期间不会阻塞主过程，然而 fork 这个霎时肯定是会阻塞主过程的。因而 fork 操作破费的工夫越长，Redis 操作提早的工夫就越长。即便在一台一般的机器上，Redis 也能够解决每秒50K到100K的操作，那么几秒钟的提早可能意味着数十万次操作的速度减慢，这可能会给应用程序带来重大的稳定性问题。

为了防止一次性拷贝大量内存数据给子过程造成的长时间阻塞问题，fork 采纳操作系统提供的写时复制（Copy-On-Write）机制，但 fork 子过程须要拷贝过程必要的数据结构，其中有一项就是拷贝内存页表（虚拟内存和物理内存的映射索引表）。这个拷贝过程会耗费大量 CPU 资源，拷贝实现之前整个过程是会阻塞的，阻塞工夫取决于整个实例的内存大小，实例越大，内存页表越大，fork 阻塞工夫越久。拷贝内存页表实现后，子过程与父过程指向雷同的内存地址空间，也就是说此时尽管产生了子过程，然而并没有申请与父过程雷同的内存大小。

参考资料：

1.极客工夫专栏《Redis源码分析与实战》.蒋德钧.2021

2.极客工夫专栏《Redis核心技术与实战》.蒋德钧.2020

3.Redis 7.0 Multi Part AOF的设计和实现.驱动 qd.2022 ：
https://developer.aliyun.com/...

4.Redis 5.0.8源码：https://github.com/redis/redi...