书接上回，上回咱们具体解说了Redis的RDB机制，RDB解决了redis数据长久化一部分的问题，为什么说一部分？因为rdb是redis中某一时刻的快照，那么在这次快照后如果数据有新的变更，它是不会被长久化下来的，必须得等到下次rdb备份。然而，生成rdb是和耗费性能的，所以它就不适宜很频繁生成。Redis为了补救这一有余提供了AOF。

AOF的全称是AppendOnlyFile，源码在aof.c。其实要害就是Append(追加)，外围原理很简略，就是如果执行完命令(set,del,expire……)后，发现有数据变动，就将这次操作作为一条日志记录到aof文件里，如果有宕机就从新加载aof文件，重放所有的改变命令就能够复原数据了。只有日志被残缺刷到了磁盘上，数据就不会失落。

配置

AOF的配置比较简单，只有如下几项。

appendonly no  # aof开关，默认敞开appendfilename "appendonly.aof"  # 保留的文件名，默认appendonly.aof# 有三种刷数据的策略appendfsync always  # always是只有有数据改变，就把数据刷到磁盘里，最平安但性能也最差appendfsync everysec  # 每隔一秒钟刷一次数据，数据安全性和性能折中，这也是redis默认和举荐的配置。 appendfsync no # 不被动刷，什么时候数据刷到磁盘里取决于操作系统，在大多数Linux零碎中每30秒提交一次，性能最好，但数据安全性最差。

源码

AOF的触发

aof如何实现，又是怎么被触发的，让咱们具体看下源码。
server.c中的void call(client *c, int flags) 是redis承受到client申请后处理申请的入口，其中会检测Redis中的数据有没有发生变化。如果有变动就会执行propagate()函数。

    dirty = server.dirty;    prev_err_count = server.stat_total_error_replies;    updateCachedTime(0);    elapsedStart(&call_timer);    c->cmd->proc(c); // 执行命令    const long duration = elapsedUs(call_timer);    c->duration = duration;    dirty = server.dirty-dirty;    if (dirty < 0) dirty = 0; 
void propagate(struct redisCommand *cmd, int dbid, robj **argv, int argc,               int flags){    if (server.in_exec && !server.propagate_in_transaction)        execCommandPropagateMulti(dbid);    /* This needs to be unreachable since the dataset should be fixed during      * client pause, otherwise data may be lossed during a failover. */    serverAssert(!(areClientsPaused() && !server.client_pause_in_transaction));    if (server.aof_state != AOF_OFF && flags & PROPAGATE_AOF)        feedAppendOnlyFile(cmd,dbid,argv,argc); // 如果aof开启了，就会向aof流传该命令。    if (flags & PROPAGATE_REPL)        replicationFeedSlaves(server.slaves,dbid,argv,argc);}

propagate函数的作用就是将带来数据改变的命令流传给slave和AOF，这里咱们只关注AOF，咱们来具体看下feedAppendOnlyFile()函数。

AOF数据生成

void feedAppendOnlyFile(struct redisCommand *cmd, int dictid, robj **argv, int argc) {    sds buf = sdsempty();    /* The DB this command was targeting is not the same as the last command     * we appended. To issue a SELECT command is needed. */    if (dictid != server.aof_selected_db) {        char seldb[64];        snprintf(seldb,sizeof(seldb),"%d",dictid);        buf = sdscatprintf(buf,"*2\r\n$6\r\nSELECT\r\n$%lu\r\n%s\r\n",            (unsigned long)strlen(seldb),seldb);        server.aof_selected_db = dictid;    }    if (cmd->proc == expireCommand || cmd->proc == pexpireCommand ||        cmd->proc == expireatCommand) {        /* 把 EXPIRE/PEXPIRE/EXPIREAT 命令转化为 PEXPIREAT 命令*/        buf = catAppendOnlyExpireAtCommand(buf,cmd,argv[1],argv[2]);    } else if (cmd->proc == setCommand && argc > 3) {        robj *pxarg = NULL;        /* When SET is used with EX/PX argument setGenericCommand propagates them with PX millisecond argument.         * So since the command arguments are re-written there, we can rely here on the index of PX being 3. */        if (!strcasecmp(argv[3]->ptr, "px")) {            pxarg = argv[4];        }        /* 把set命令的expired所带的绝对工夫转化为相对工夫(ms). */        if (pxarg) {            robj *millisecond = getDecodedObject(pxarg);            long long when = strtoll(millisecond->ptr,NULL,10);            when += mstime();            decrRefCount(millisecond);            robj *newargs[5];            newargs[0] = argv[0];            newargs[1] = argv[1];            newargs[2] = argv[2];            newargs[3] = shared.pxat;            newargs[4] = createStringObjectFromLongLong(when);            buf = catAppendOnlyGenericCommand(buf,5,newargs);            decrRefCount(newargs[4]);        } else {            buf = catAppendOnlyGenericCommand(buf,argc,argv);        }    } else {        /* 其余的命令都不须要转化 */        buf = catAppendOnlyGenericCommand(buf,argc,argv);    }    /* 追加到AOF缓冲区。在从新进入事件循环之前，数据将被刷新到磁盘上，因而在客户端在执行前就会失去回复。*/    if (server.aof_state == AOF_ON)        server.aof_buf = sdscatlen(server.aof_buf,buf,sdslen(buf));    /* 如果后盾正在进行AOF重写，咱们心愿将子数据库和以后数据库之间的差别累积到缓冲区中，     * 以便在子过程执行其工作时，咱们能够将这些差别追加到新的只追加文件中。 */    if (server.child_type == CHILD_TYPE_AOF)        aofRewriteBufferAppend((unsigned char*)buf,sdslen(buf));    sdsfree(buf);}

这里没有啥太简单的逻辑，就是将命令转化为RESP协定格局的字符串(RESP协定后续会详解)，而后追加到server.aof_buf中，这时候AOF数据还都在缓冲区中，并没有写入到磁盘中，那buf中的数据何时写入磁盘呢？

刷数据

刷数据的外围代码在flushAppendOnlyFile()中，flushAppendOnlyFile在serverCron、beforeSleep和prepareForShutdown中都有被调用，它的作用就是将缓冲区的数据写到磁盘中，代码比拟长且简单，但大部分都是异样解决和性能监控，疏忽掉这部分后代码也比拟容易了解，这里就不再列举了，详见aof.c。

RDB vs AOF

最初，咱们来比照下RDB和AOF，他们各自都有啥优缺点，该如何选用。

RDB的劣势

  1. RDB是压缩的后紧凑数据格式，比拟很适宜备份，
  2. 同样的数据量下，rdb的文件大小会很小，比拟适宜传输和数据恢复。
  3. RDB对Redis的读写性能影响小，生成RDB的时redis主过程会fork出一个子过程，不会影响到主过程的读写。
  4. RDB数据加载更快，复原起来更快。

RDB的毛病

  1. RDB是定期备份，如果备份前产生宕机，数据可能会失落。
  2. RDB的生成依赖于linux的fork，如果数据量比拟大的话，很影响服务器性能。

AOF的劣势

  1. AOF是持续性备份，能够尽可能保证数据不失落。
  2. Redis太大时，Redis能够在后盾主动重写AOF。重写是齐全平安的，因为Redis持续追加到旧文件时，会生成一个全新的文件，其中蕴含创立以后数据集所需的起码操作集，一旦筹备好第二个文件，Redis会切换这两个文件并开始追加到新的那一个。

  3. AOF文件格式简略，易于解析。

    AOF的毛病

  4. 对于同一数据集，AOF文件大小通常大于等效的RDB文件。
  5. 如果应用fsync策略，AOF可能比RDB慢。

RDB和AOF该如何选

如果是要求极致的性能，但对数据恢复不敏感，二者能够都不要，如果是关注性能且关注数据可用性，但不要求数据完整性，能够选用RDB。如果说十分关注数据完整性和宕机复原的能力，能够RDB+AOF同时开启。

参考资料

  1. Redis persistence demystified
  2. Redis Persistence
本文是Redis源码分析系列博文，同时也有与之对应的Redis中文正文版，有想深刻学习Redis的同学，欢送star和关注。
Redis中文注解版仓库：https://github.com/xindoo/Redis
Redis源码分析专栏：https://zxs.io/s/1h
如果感觉本文对你有用，欢送一键三连。