Redis从入门到精通【进阶篇】之持久化 AOF详解

0.前言

Redis 支持多种持久化方式来保证数据的可靠性和持久性。其中AOF（Append Only File）机制是一种常用的持久化方式，它记录了所有对 Redis 数据库进行修改的命令，在 Redis 重启时可以使用这些命令来重构数据库状态。本文将详细介绍 Redis AOF 持久化机制的实现原理。

1.详解

在 Redis 的配置文件中，可以通过以下配置项来设置 AOF 持久化相关的参数

1. appendonly：设置是否开启 AOF 持久化，默认为 no（关闭状态）。

2. appendfilename：设置 AOF 文件名，默认为 appendonly.aof。

3. appendfsync：设置 AOF 文件同步策略，有以下三种可选值：

- always：每次写入都会同步到磁盘，最安全但性能最差；
- everysec：每秒同步一次到磁盘，安全性和性能的折中方案；
- no：由操作系统决定何时同步，最不安全但性能最好。

4. auto-aof-rewrite-percentage：设置 AOF 重写触发的条件之一，即 AOF 文件大小增长率达到该值时触发 AOF 重写，默认为 100。

5. auto-aof-rewrite-min-size：设置 AOF 重写触发的条件之一，即 AOF 文件大小达到该值时触发 AOF 重写，默认为 64MB。

6. aof-load-truncated：设置当 Redis 以 AOF 模式启动时，是否自动修复截断的 AOF 文件，默认为 yes。

7. aof-use-rdb-preamble：设置是否在 AOF 文件中使用 RDB 文件的前缀，默认为 yes。

需要注意的是，修改 Redis 配置文件后，需要重启 Redis 才能使配置生效。同时，对于 AOF
文件同步策略的选择，需要根据实际情况进行权衡和选择。如果对数据的安全性要求非常高，可以选择 always
策略；如果对性能的要求比较高，可以选择 everysec 策略。

1.1 AOF 文件的创建

当启用 AOF 持久化机制时，Redis 会在启动时创建一个 AOF 文件，用于记录所有写命令。AOF 文件的默认文件名为 appendonly.aof，可以通过配置文件中的 appendfilename 参数进行修改。如果 AOF 文件已经存在，则 Redis 会在启动时读取文件中的内容，并将其加载到内存中。

1.2. AOF 文件的写入

当 Redis 执行写命令时，会将命令追加到 AOF 文件的末尾。如果 AOF 文件不存在，则 Redis 会自动创建一个新的 AOF 文件。如果 AOF 文件已经存在，则 Redis 会将命令追加到文件的末尾。

Redis 为了提高写入性能，通常会将多个命令缓存到内存中，然后在满足一定条件时批量写入到 AOF 文件中。具体来说，Redis 会维护一个 AOF 缓冲区，将每个写命令追加到缓冲区的末尾。当缓冲区的大小超过一定阈值时，或者缓冲区中的命令已经等待了一定时间后，Redis 会将缓冲区中的命令批量写入到 AOF 文件中。

1.3. AOF 文件的同步

为了保证写命令的可靠性和持久性，Redis 会在写入 AOF 文件后进行同步操作，将数据从内存中刷到磁盘中。这就是我通常所说的刷盘操作。刷盘操作可以分为两种方式：

1. 3.1 同步磁盘上的所有数据

每次写入 AOF 文件时，Redis 会调用 fsync 系统调用将数据从内存刷到磁盘中。这种方式可以保证数据的可靠性，但是会带来较大的性能损耗。

1. 3.2 定期同步磁盘上的数据

Redis 也可以通过配置文件中的 appendfsync 参数来控制 AOF 文件的同步方式。其中，有三种常用的方式：

• always：每次写入 AOF 文件时都进行同步操作，可以保证数据的可靠性，但是会带来较大的性能损耗。
• everysec：每秒钟对 AOF 文件进行一次同步操作，可以在一定程度上平衡数据安全和性能需求。
• no：不进行同步操作，只在 Redis 进程退出时进行一次同步操作，可以提高性能，但是会带来一定的数据风险。
  
  总结一下

1. 如果要高性能，就选择 No 策略；
2. 如果要高可靠，就选择 Always 策略；
3. 如果允许数据丢失一点，但又想性能高，就选择 Everysec策略。

其实在源码中这三种策略只是在控制 fsync() 函数的调用时机
当应用程序向文件写入数据时，内核通常先将数据复制到内核缓冲区中，然后排入队列，然后由内核决定何时写入硬盘。

// AOF 持久化主函数。只在rewriteAppendOnlyFileBackground() 中会调用此函数
/* Write a sequence of commands able to fully rebuild the dataset into
* "filename". Used both by REWRITEAOF and BGREWRITEAOF.
**
In order to minimize the number of commands needed in the rewritten
* log Redis uses variadic commands when possible, such as RPUSH, SADD
* and ZADD. However at max REDIS_AOF_REWRITE_ITEMS_PER_CMD items per time
* are inserted using a single command. */
    int rewriteAppendOnlyFile(char *filename) {
    
    
    dictIterator *di = NULL;
    dictEntry *de;
    rio aof;
    FILE *fp;
    char tmpfile[256];
    int j;
    long long now = mstime();
    /* Note that we have to use a different temp name here compared to the
    * one used by rewriteAppendOnlyFileBackground() function. */

    snprintf(tmpfile,256,"temp-rewriteaof-%d.aof", (int) getpid());
    // 打开文件
    fp = fopen(tmpfile,"w");
    if (!fp) {
    
    
        redisLog(REDIS_WARNING, "Opening the temp file for AOF rewrite in"
        "rewriteAppendOnlyFile(): %s", strerror(errno));
        return REDIS_ERR;
    }
        // 初始化rio 结构体
        rioInitWithFile(&aof,fp);
        // 如果设置了自动备份参数，将进行设置
    if (server.aof_rewrite_incremental_fsync)
        rioSetAutoSync(&aof,REDIS_AOF_AUTOSYNC_BYTES);
        // 备份每一个数据集
    for (j = 0; j < server.dbnum; j++) {
    
    
        char selectcmd[] = "*2\r\n$6\r\nSELECT\r\n";
        redisDb *db = server.db+j;
        dict *d = db->dict;
    if (dictSize(d) == 0) continue;
        // 获取数据集的迭代器
        di = dictGetSafeIterator(d);
    if (!di) {
    
    
        fclose(fp);
        return REDIS_ERR;
    }
    // 写入AOF 操作码
    /* SELECT the new DB */
    if (rioWrite(&aof,selectcmd,sizeof(selectcmd)-1) == 0) goto werr;
    // 写入数据集序号
    if (rioWriteBulkLongLong(&aof,j) == 0) goto werr;
    // 写入数据集中每一个数据项
    /* Iterate this DB writing every entry */
    while((de = dictNext(di)) != NULL) {
    
    
        sds keystr;
        robj key, *o;
        long long expiretime;
        keystr = dictGetKey(de);
        o = dictGetVal(de);
        // 将keystr 封装在robj 里
        initStaticStringObject(key,keystr);
        // 获取过期时间
        expiretime = getExpire(db,&key);

        // 如果已经过期，放弃存储
        /* If this key is already expired skip it */
    if (expiretime != -1 && expiretime < now) continue;
        // 写入键值对应的写操作
        /* Save the key and associated value */
    if (o->type == REDIS_STRING) {
    
    
        /* Emit a SET command */
        char cmd[]="*3\r\n$3\r\nSET\r\n";
    if (rioWrite(&aof,cmd,sizeof(cmd)-1) == 0) goto werr;
        /* Key and value */
    if (rioWriteBulkObject(&aof,&key) == 0) goto werr;
    if (rioWriteBulkObject(&aof,o) == 0) goto werr;
    } else if (o->type == REDIS_LIST) {
    
    
    if (rewriteListObject(&aof,&key,o) == 0) goto werr;
    } else if (o->type == REDIS_SET) {
    
    
    if (rewriteSetObject(&aof,&key,o) == 0) goto werr;
    } else if (o->type == REDIS_ZSET) {
    
    
    if (rewriteSortedSetObject(&aof,&key,o) == 0) goto werr;
    } else if (o->type == REDIS_HASH) {
    
    
    if (rewriteHashObject(&aof,&key,o) == 0) goto werr;
    } else {
    
    
        redisPanic("Unknown object type");
    }
    // 写入过期时间
    /* Save the expire time */
    if (expiretime != -1) {
    
    
        char cmd[]="*3\r\n$9\r\nPEXPIREAT\r\n";
    if (rioWrite(&aof,cmd,sizeof(cmd)-1) == 0) goto werr;
    if (rioWriteBulkObject(&aof,&key) == 0) goto werr;
    if (rioWriteBulkLongLong(&aof,expiretime) == 0) goto werr;
    }
}
    // 释放迭代器
    dictReleaseIterator(di);
}
    // 写入磁盘
    /* Make sure data will not remain on the OS's output buffers */
    fflush(fp);
    aof_fsync(fileno(fp));
    fclose(fp);
    // 重写文件名
    /* Use RENAME to make sure the DB file is changed atomically only
    * if the generate DB file is ok. */
    if (rename(tmpfile,filename) == -1) {
    
    
        redisLog(REDIS_WARNING,"Error moving temp append only file on the "
        "final destination: %s", strerror(errno));
        unlink(tmpfile);
        return REDIS_ERR;
    }
    redisLog(REDIS_NOTICE,"SYNC append only file rewrite performed");
    return REDIS_OK;
    werr:
    // 清理工作
    fclose(fp);
    unlink(tmpfile);
    redisLog(REDIS_WARNING,"Write error writing append only file on disk: "
    "%s", strerror(errno));
    if (di) dictReleaseIterator(di);
        return REDIS_ERR;
}

1.4. AOF 文件的重写

Redis AOF 文件在长时间运行后可能会变得非常大，不仅占用磁盘空间，还会影响 Redis 的性能。为了解决这个问题，Redis 提供了 AOF 文件重写机制，可以将 AOF 文件中的写命令进行压缩，生成一条等效的命令序列，从而减少 AOF 文件的大小。

AOF 文件重写机制的实现原理如下：

（1）Redis 会启动一个新的子进程，用于执行 AOF 文件重写操作。

（2）Redis 主进程会将所有写命令发送到子进程中，子进程会执行这些命令，并生成一条等效的命令序列。

（3）子进程会将等效命令序列写入到一个新的 AOF 文件中，同时在写入过程中进行同步操作，保证数据的可靠性。

（4）当子进程完成 AOF 文件的重写操作后，Redis 主进程会将新的 AOF 文件重命名为原来的 AOF 文件，并删除旧的 AOF 文件。

需要注意的是，AOF 文件重写操作只会对已经执行过的写命令进行压缩，新的写命令仍然会被追加到 AOF 文件的末尾。Redis 会周期性地检查 AOF 文件的大小，并在满足一定条件时触发 AOF 文件重写操作。

1.5. AOF 文件的恢复

AOF 的数据恢复过程设计很巧妙，它模拟一个 Redis 的服务过程。Redis 首先虚拟一个客户端，读取 AOF 文件恢复 Redis 命令和参数；接着过程就和服务客户端一样执行命令相应的函数，从而恢复数据，这样做的目的无非是提高代码的复用率。这些过程主要在 loadAppendOnlyFile() 中实现。我们可以理解为假的重放。

真实的过程当 Redis 重启时，会根据 AOF 文件中记录的命令重构数据库状态。具体来说，Redis 会按照 AOF 文件中记录的命令顺序，逐个执行命令，并在执行过程中重建数据库状态。需要注意的是，AOF 文件的恢复过程可能会比较耗时，因此需要在 Redis 配置文件中设置 AOF 文件的恢复方式，可以选择同步方式（always、everysec）或异步方式（no）。

所以，Redis AOF 持久化机制，其实说白了就是redis启动的时候创建一个server.aof_buf的文件，通过一个文件，实现了将写命令追加到 AOF 文件中，并在需要时同步到磁盘中，从而保证了数据的可靠性和持久性。 当异常宕机需要恢复数据的时候又通过读取文件，回放之前的命令，进行数据还原。
由此大家也可以推断出它存在的弊端。

1.6. 小结

1. 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

2. 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。

3. 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

到此我们学完了 Redis 的持久化方式 RDB 和AOF 。那么我们对比一下。整理出如下表格

	RDB	AOF
启动优先级	低	高
体积	比 AOF 小	比 RDB 大
恢复速度	比 AOF 快	比 RDB 慢
数据安全性	在定时备份时可能会丢失一定量的数据	根据同步策略决定，相对更安全
数据一致性	RDB 持久化的数据可能不是最新的，但数据一致性较高	AOF 持久化的数据较新，但数据一致性较低
运维复杂度	相对简单，只需要定期备份 RDB 文件即可	相对复杂，需要配置 AOF 缓冲区大小、同步策略等参数
写入性能	相对较高，因为 RDB 只需要生成一次快照文件即可完成持久化操作	相对较低，因为 AOF 需要将每一次写操作都写入到 AOF 文件中
读取性能	相对较高，因为 RDB 文件读取速度快	相对较低，因为需要将 AOF 文件中的所有写操作都执行一遍才能恢复
文件格式	二进制格式，比较紧凑	文本格式，可读性好
恢复方式	通过加载 RDB 文件来恢复数据库	通过加载 AOF 文件并执行其中的写操作来恢复数据库
文件重写方式	通过 BGSAVE 命令生成新的 RDB 文件来实现文件重写	通过执行 BGREWRITEAOF 命令来生成新的 AOF 文件实现文件重写

2. RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

混合方式可以同时利用 RDB 的快速恢复和 AOF 的数据安全性。在这种混合方式下，Redis 会同时生成 RDB 文件和 AOF 文件，来保证数据的安全性和可靠性。

具体来说，可以采用如下的持久化配置：

1. 将 AOF 模式设置为 always，并设置合适的同步策略，以确保 Redis 在执行写操作时，都将对应的操作写入 AOF 文件中。

2. 在 Redis 中启用 RDB 持久化，并设置一个合适的持久化间隔，以确保 Redis 在每隔一定时间内，执行一次 RDB 文件的快照生成操作。

3. 将 Redis 配置为在启动时，先尝试使用 AOF 文件进行恢复，如果 AOF 文件不存在或损坏，则使用 RDB 文件进行恢复。
   从网上找个图方便大家理解
   

通过这种方式，可以将 RDB 和 AOF 的优点结合起来，从而达到更加全面的数据保护和恢复能力。同时也需要注意，这种方式会带来一定的存储和性能开销，需要根据实际情况进行权衡和优化。

好了，本次的分享就到这儿，下次见，如果对本文有疑惑或者争议都可以评论区留言。看到我会回复。大家如果想了解其他的，可以看我的专栏其他文章如下。

3. Redis从入门到精通系列文章

《Redis从入门到精通【进阶篇】之持久化RDB》
《Redis从入门到精通【高阶篇】之底层数据结构字典(Dictionary)详解》
《Redis从入门到精通【高阶篇】之底层数据结构快表QuickList详解》
《Redis从入门到精通【高阶篇】之底层数据结构简单动态字符串(SDS)详解》
《Redis从入门到精通【高阶篇】之底层数据结构压缩列表(ZipList)详解》
《Redis从入门到精通【进阶篇】之数据类型Stream详解和使用示例》