Redis支持RDB和AOF两种持久化机制。通过info persistence查看持久化相关配置项，如下

127.0.0.1:6379> info persistence

# Persistence

loading:0

rdb_changes_since_last_save:0

rdb_bgsave_in_progress:0

rdb_last_save_time:1611742479

rdb_last_bgsave_status:ok

rdb_last_bgsave_time_sec:1

rdb_current_bgsave_time_sec:-1

aof_enabled:0

aof_rewrite_in_progress:0

aof_rewrite_scheduled:0

aof_last_rewrite_time_sec:-1

aof_current_rewrite_time_sec:-1

aof_last_bgrewrite_status:ok

aof_last_write_status:ok

• loading 这个值为1时，表示服务器正在进行RDB或AOF载入
  RDB文件状态监控相关的参数
• rdb_changes_since_last_save 表明上次RDB保存以后改变的key次数
• rdb_bgsave_in_progress表示当前是否在进行bgsave操作。是为1
• rdb_last_save_time 上次保存RDB文件的时间戳
• rdb_last_bgsave_time_sec 上次保存的耗时
• rdb_last_bgsave_status 上次保存的状态
• rdb_current_bgsave_time_sec 目前保存RDB文件已花费的时间
  AOF文件状态监控相关的参数
• aof_enabled AOF文件是否启用
• aof_rewrite_in_progress 表示当前是否在进行写入AOF文件操作
• aof_rewrite_scheduled
• aof_last_rewrite_time_sec 上次写入的时间戳
• aof_current_rewrite_time_sec当前写入的时间戳
• aof_last_bgrewrite_status 上次写入状态
• aof_last_write_status 上次写入状态

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，可以通过手动和自动两种方式进行RDB持久化。

触发方式

• 手动触发
  命令 | 执行流程 | 执行进程 | 阻塞
  ----|:---- |-----|----
  save | 阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用 ,由于该命令会阻塞Redis服务进程，因此已被废弃，更多的还是使用bgsave | 父进程处理 | 阻塞
  bgsave | Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。bgsave是当前主流触发RDB持久化的方式 | 子进程处理 | 只有fork阶段阻塞，其余由子进程处理不会阻塞
• 自动触发

1. 使用save相关配置，如save m n。表示m秒内数据集存在n次修改 时，自动触发bgsave。
2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
3. 执行debug reload命令重新加载Redis时，也会自动触发save操作。
4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

执行流程

如下是 bgsave 的主要方法的执行逻辑：

int rdbSaveBackground(char *filename) {

   pid_t childpid;

   long long start;

   // 如果 BGSAVE 已经在执行，那么出错

   if (server.rdb_child_pid != -1) return REDIS_ERR;

   // 记录 BGSAVE 执行前的数据库被修改次数

   server.dirty_before_bgsave = server.dirty;

   // 最近一次尝试执行 BGSAVE 的时间

   server.lastbgsave_try = time(NULL);

   // fork() 开始前的时间，记录 fork() 返回耗时用

   start = ustime();

   if ((childpid = fork()) == 0) {

       int retval;

       /* Child */

       // 关闭网络连接 fd

       closeListeningSockets(0);

       // 设置进程的标题，方便识别

       redisSetProcTitle("redis-rdb-bgsave");

       // 执行保存操作

       retval = rdbSave(filename);

       // 打印 copy-on-write 时使用的内存数

       if (retval == REDIS_OK) {

           size_t private_dirty = zmalloc_get_private_dirty();

           if (private_dirty) {

               redisLog(REDIS_NOTICE,

                   "RDB: %zu MB of memory used by copy-on-write",

                   private_dirty/(1024*1024));

           }

       }

       // 向父进程发送信号

       exitFromChild((retval == REDIS_OK) ? 0 : 1);

   } else {

       /* Parent */

       // 计算 fork() 执行的时间

       server.stat_fork_time = ustime()-start;

       // 如果 fork() 出错，那么报告错误

       if (childpid == -1) {

           server.lastbgsave_status = REDIS_ERR;

           redisLog(REDIS_WARNING,"Can't save in background: fork: %s",

               strerror(errno));

           return REDIS_ERR;

       }

       // 打印 BGSAVE 开始的日志

       redisLog(REDIS_NOTICE,"Background saving started by pid %d",childpid);

       // 记录数据库开始 BGSAVE 的时间

       server.rdb_save_time_start = time(NULL);

       // 记录负责执行 BGSAVE 的子进程 ID

       server.rdb_child_pid = childpid;

       // 关闭自动 rehash

       updateDictResizePolicy();

       return REDIS_OK;

   }

   return REDIS_OK; /* unreached */

}

1. 执行bgsave命令， Redis父进程判断当前是否存在正在执行的子进程， 如RDB/AOF子进程， 如果存在直接返回
2. 父进程执行fork操作创建子进程， fork操作过程中父进程会阻塞
3. 父进程fork完成后， bgsave命令返回“Background saving started”信息并不再阻塞父进程， 可以继续响应其他命令
4. 子进程创建RDB文件， 根据父进程内存生成临时快照文件， 完成后
   对原有文件进行原子替换
5. 进程发送信号给父进程表示完成， 父进程更新统计信息

rdb相关参数

RDB文件格式

• 魔数 恒为REDIS，用来标记文件开头，这里类似Java中的CAFEBABE
• 版本号 记录REDIS_RDB_VERSION的rdb版本。由于历史不同版本下可能存在不兼容的情况
• 数据库编号 当前持久化的数据库编号
• 数据库数据 数据库数据

• 带有过期时间

• TYPE 长度为1字节，记录value的类型
• key 类型总是string
• value 根据TYPE指定的类型进行存储

• 不带有过期时间

• EXPIRETIME_MS 长度为1字节，标记后面是毫秒为单位的过期时间
• ms 8字节长的带符号整数，记录的是过期时间的时间戳

• EOF 代表数据库结尾
• 校验和 如果开启了文件校验和功能，则写入CRC64校验和。校验和是根据魔数、版本号 、数据库数据 、EOF 计算出的，用来快速检查RDB文件完整性
  RDB文件持久化方法如下：

/* Save the DB on disk. Return REDIS_ERR on error, REDIS_OK on success

*

* 将数据库保存到磁盘上。

*

* 保存成功返回 REDIS_OK ，出错/失败返回 REDIS_ERR 。

*/

int rdbSave(char *filename) {

   dictIterator *di = NULL;

   dictEntry *de;

   char tmpfile[256];

   char magic[10];

   int j;

   long long now = mstime();

   FILE *fp;

   rio rdb;

   uint64_t cksum;

   // 创建临时文件

   snprintf(tmpfile,256,"temp-%d.rdb", (int) getpid());

   fp = fopen(tmpfile,"w");

   if (!fp) {

       redisLog(REDIS_WARNING, "Failed opening .rdb for saving: %s",

           strerror(errno));

       return REDIS_ERR;

   }

   // 初始化 I/O

   rioInitWithFile(&rdb,fp);

   // 设置校验和函数

   if (server.rdb_checksum)

       rdb.update_cksum = rioGenericUpdateChecksum;

   // 写入 RDB 版本号

   snprintf(magic,sizeof(magic),"REDIS%04d",REDIS_RDB_VERSION);

   if (rdbWriteRaw(&rdb,magic,9) == -1) goto werr;

   // 遍历所有数据库

   for (j = 0; j < server.dbnum; j++) {

       // 指向数据库

       redisDb *db = server.db+j;

       // 指向数据库键空间

       dict *d = db->dict;

       // 跳过空数据库

       if (dictSize(d) == 0) continue

       // 创建键空间迭代器

       di = dictGetSafeIterator(d);

       if (!di) {

           fclose(fp);

           return REDIS_ERR;

       }

       /* Write the SELECT DB opcode

        *

        * 写入 DB 选择器

        */

       if (rdbSaveType(&rdb,REDIS_RDB_OPCODE_SELECTDB) == -1) goto werr;

       if (rdbSaveLen(&rdb,j) == -1) goto werr;

       /* Iterate this DB writing every entry

        *

        * 遍历数据库，并写入每个键值对的数据

        */

       while((de = dictNext(di)) != NULL) {

           sds keystr = dictGetKey(de);

           robj key, *o = dictGetVal(de);

           long long expire;

         

           // 根据 keystr ，在栈中创建一个 key 对象

           initStaticStringObject(key,keystr);

           // 获取键的过期时间

           expire = getExpire(db,&key);

           // 保存键值对数据

           if (rdbSaveKeyValuePair(&rdb,&key,o,expire,now) == -1) goto werr;

       }

       dictReleaseIterator(di);

   }

   di = NULL; /* So that we don't release it again on error. */

   /* EOF opcode

    *

    * 写入 EOF 代码

    */

   if (rdbSaveType(&rdb,REDIS_RDB_OPCODE_EOF) == -1) goto werr;

   /* CRC64 checksum. It will be zero if checksum computation is disabled, the

    * loading code skips the check in this case.

    *

    * CRC64 校验和。

    *

    * 如果校验和功能已关闭，那么 rdb.cksum 将为 0 ，

    * 在这种情况下， RDB 载入时会跳过校验和检查。

    */

   cksum = rdb.cksum;

   memrev64ifbe(&cksum);

   rioWrite(&rdb,&cksum,8);

   /* Make sure data will not remain on the OS's output buffers */

   // 冲洗缓存，确保数据已写入磁盘

   if (fflush(fp) == EOF) goto werr;

   if (fsync(fileno(fp)) == -1) goto werr;

   if (fclose(fp) == EOF) goto werr;

   /* Use RENAME to make sure the DB file is changed atomically only

    * if the generate DB file is ok.

    *

    * 使用 RENAME ，原子性地对临时文件进行改名，覆盖原来的 RDB 文件。

    */

   if (rename(tmpfile,filename) == -1) {

       redisLog(REDIS_WARNING,"Error moving temp DB file on the final destination: %s", strerror(errno));

       unlink(tmpfile);

       return REDIS_ERR;

   }

   // 写入完成，打印日志

   redisLog(REDIS_NOTICE,"DB saved on disk");

   // 清零数据库脏状态

   server.dirty = 0;

   // 记录最后一次完成 SAVE 的时间

   server.lastsave = time(NULL);

   // 记录最后一次执行 SAVE 的状态

   server.lastbgsave_status = REDIS_OK;

   return REDIS_OK;

werr:

   // 关闭文件

   fclose(fp);

   // 删除文件

   unlink(tmpfile);

   redisLog(REDIS_WARNING,"Write error saving DB on disk: %s", strerror(errno));

   if (di) dictReleaseIterator(di);

   return REDIS_ERR;

}

对象文件编码

字符串对象

字符串对象编码分类如下：

列表对象

这里以 双端链表 实现举例

集合对象

这里以 字典 实现举例

哈希对象

这里以 字典 实现举例

有序集合对象

这里以 跳跃表 实现举例

文件压缩

Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的 文件远远小于内存大小，默认开启。可以参考[redis源码]LZF压缩算法
可以通过参数config set rdbcompression{yes|no}动态修改

优缺点

• 优点

• RDB是一个紧凑压缩的二进制文件， 代表Redis在某个时间点上的数据快照。 非常适用于备份， 全量复制等场景进行有效灾备。
• 由于是紧凑压缩的二进制文件，因此Redis加载RDB恢复数据远远快于AOF的方式。

• 缺点

• 数据无法实时持久化/秒级持久化。 因为bgsave每次运行都要执行fork操作创建子进程， 属于重量级操作， 频繁执行成本过高。
• 存在老版本无法兼容新版RDB格式。RDB文件使用特定二进制格式保存，演进过程中有多个格式的RDB版本。

AOF

AOF（append only file）与RDB保持数据库键值对对象的二进制文本不同，它采用记录Redis的文本格式命令的形式进行持久化。

执行频率

可以通过appendfsync控制

write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓 冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。

fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将 阻塞直到写入硬盘完成后返回，保证了数据持久化

感兴趣的话，可以参考下mysql的刷盘机制进行对比

执行流程

AOF的执行流程主要有：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

1. 所有的写入命令会追加到aof_buf（缓冲区）中。
2. AOF缓冲区根据对应的策略向硬盘做同步操作。
3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩 的目的。
4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

重写压缩

随着命令不断写入AOF，文件会越来越大，为了减少存储占用和更快地在重启阶段加载Redis，Redis 引入AOF重写机制压缩文件体积。

压缩文件空间的来源：

• 过期数据不再写入
• 覆盖重复执行命令后只保留最终命令。如set key aaa，set key bbb
• 合并命令，如lpush list a、lpush list b、lpush list c可以转化为lpush list a b c

触发机制

如下图，是重写压缩的执行流程

• fork子进程处理aof文件重写工作
• 父进程接收命令后会双写aof_buff、aof_rewrite_buff这两块缓冲区，以确保重写过程也可以接收新命令，防止命令丢失
• 最终新重写压缩的AOF文件会覆盖旧AOF文件，达到节省空间的目的
  重写机制的触发也分为手动和自动两种。
• 手动触发
  直接调用bgrewriteaof命令。
• 自动触发
  根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

• auto-aof-rewrite-min-size 表示运行AOF重写时文件最小体积，默认 为64MB。
• auto-aof-rewrite-percentage 代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比 值。
• 自动触发时机 = aof_current_size>auto-aof-rewrite-min- size &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite- percentage

优缺点

• 优点

• 基于Redis命令文本格式，有较好的可读性
• 不需要像rdb那样进行序列化二次处理，实现简单
• 提供了较为灵活的appendfsync刷盘策略控制

• 缺点

• 直接存储，没有进行压缩，占用空间大（但是也提供了rewrite机制进行压缩控制）
• 由于是文本命令的直接操作回放，重载恢复数据比rdb时间长

重启加载

如下是重启加载持久化文件数据到内存的执行流程，会优先加载AOF文件，如果加载不成功会尝试加载RDB文件

/* Function called at startup to load RDB or AOF file in memory. */

void loadDataFromDisk(void) {

   // 记录开始时间

   long long start = ustime();

   // AOF 持久化已打开？

   if (server.aof_state == REDIS_AOF_ON) {

       // 尝试载入 AOF 文件

       if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)

           // 打印载入信息，并计算载入耗时长度

           redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);

   // AOF 持久化未打开

   } else {

       // 尝试载入 RDB 文件

       if (rdbLoad(server.rdb_filename) == REDIS_OK) {

           // 打印载入信息，并计算载入耗时长度

           redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",

               (float)(ustime()-start)/1000000);

       } else if (errno != ENOENT) {

           redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));

           exit(1);

       }

   }

}

总结

• 基于rdb文件的bgsave和基于aof文件的bgrewriteaof会彼此阻塞，当有一方执行时另一方被禁止执行，双方都是通过fork子进程进行的并不存在冲突，这里只是性能考虑而这样进行设计的
• Redis无论在哪种持久化机制下，即使在Redis中最可靠的持久化方式也无法保证100%可靠，只能是相对可靠。当appendfsync刷盘策略开启为always可以保证每次写入缓冲区后立刻调用fsync刷盘持久化，但是这并不是一个原子性操作，中间出现异常便持久化失败
• 我们通常会充分利用Redis的高性能，把它作为一个支持多种数据结构的纯缓存中间件来进行使用，一般情况下为了追求高性能会牺牲持久性方面的考虑

参考

《Redis开发与运维》
《Redis设计与实现》
http://blog.sina.com.cn/s/blog_9599e9510101cpra.html RDB文件格式
https://blog.csdn.net/yitouhan/article/details/108035859 Redis的LZF压缩算法
https://www.cnblogs.com/zengkefu/p/5634746.html 持久化