• 前言
• 1. RDB 持久化
  • 1.1 RDB 文件的创建与载入
  • 1.2 自动间隔性保存
    • 1.2.1 设置保存条件
    • 1.2.2 dirty 计数器和 lastsave 属性
    • 1.2.3 检查保存条件是否满足
  • 1.3 RDB 文件
    • 1.3.1 RDB 的文件结构
    • 1.3.2 database 的文件结构
    • 1.3.3 key_value_pairs 的文件结构
    • 1.3.4 value 的编码
  • 1.4 RDB 文件的示例
• 2 AOF 持久化与 RDB 持久化的区别
• 3. AOF 持久化
  • 3.1 AOF 持久化的实现
  • 3.2 AOF 文件的载入与数据还原
  • 3.3 AOF 重写
  • 3.4 AOF 后台重写
• 最后

前言

参考资料：《Redis设计与实现 第二版》；

第二部分为单机数据库的实现，主要由以下模块组成：数据库、持久化、事件、客户端与服务器；

本篇将介绍 Redis 中的持久化技术，主要有两种：RDB持久化和AOF持久化；

1. RDB 持久化

1.1 RDB 文件的创建与载入

• Redis使用 SAVE 和 BGSAVE 命令生成 RDB 文件；
  • SAVE：会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，阻塞期间服务器不能处理任何命令请求；
  • BGSAVE：会派生一个子进程，由指进程负责创建 RDB 文件，父进程继续处理命令请求。BGSAVE 执行期间，会发生以下特殊情况：
    • 在 BGSAVE 命令执行期间，客户端发送 SAVE 和 BGSAVE 命令会被服务器拒绝，防止产生竞争条件。客户端发送 BGREWRITEAOF 命令会被延迟；
    • 在 BGREWRITEAOF 命令执行期间，客户端发送 BGSAVE 命令会被服务器拒绝；
• 创建 RDB 文件由 rdb.c/rdbSave 函数完成；
• 载入 RDB 文件由 rdb.c/rdbLoad 函数完成；
• RDB 文件的载入工作是在服务器启动时自动执行，只要 Redis 服务器在启动时检测到 RDB 文件存在，就会自动载入 RDB 文件；
• AOF 文件的更新频率通常比 RDB 文件更新频率高：
  • 当服务器开启了 AOF 持久化功能时，会优先使用 AOF 文件还原数据库状态；
  • 当服务器关闭了 AOF 持久化功能时，才会使用 RDB 文件来还原数据库状态；
• 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止；

1.2 自动间隔性保存

1.2.1 设置保存条件

• 服务器会根据 save 选项所设置的保存值，设置服务器状态 redisServer结构的 saveparams 属性；

• redisServer 的结构定义：

  struct redisServer{
      //...
      //记录了保存条件的数组
      struct saveparam *saveparams;
      //
  }
  

• saveparams 属性是一个数组，每个 saveparam 结构保存了一个 save 设置的保存条件；

• saveparam 的结构定义：

  struct saveparam{
      //秒数
      time_t seconds;
      //修改值
      int changes;
  }
  

1.2.2 dirty 计数器和 lastsave 属性

• dirty 属性和 lastsave 属性在 redisServer 结构体里：

  struct redisServer{
      //...
      //修改计数器
      long long dirty;
      //上一次执行保存的时间
      time_t lastsave;
  };
  

  • dirty 计数器记录距离上一次成功执行 SAVE 命令或者 BGNAME 命令之后，服务器对数据库状态进行了多少次修改；
  • lastsave 属性是一个 UNIX 时间戳，记录了服务器上一次成功执行 SAVE 命令或 BGSAVE 命令的时间；

1.2.3 检查保存条件是否满足

• Redis 的服务器周期性操作函数 serverCron 默认每隔 100ms 会执行一次，其中包括检查 save 选项所设置的保存条件是否满足（遍历并检查 saveparams 数组中的所有保存条件），满足则执行 BGSAVE 命令；

1.3 RDB 文件

1.3.1 RDB 的文件结构

• RDB 文件结构的逻辑图：
  

• 各个字段含义：

  字段	长度	储存值	说明
  REDIS	5字节	“REDIS”	在载入文件时，快速检查所载入的文件是否为 RDB 文件
  db_version	4字节	字符串表示的整数	RDB 文件的版本号
  databases			0个或任意多个数据库，以及数据库中的键值对数据
  EOP	1字节	EOP 常量	表示 RDB 文件正文内容的结束
  check_sum	8字节	无符号整数	前4个部分的校验和

1.3.2 database 的文件结构

• database 为 RDB 文件的结构组成部分；
• databases 部分的逻辑结构：

• 各字段含义：

  字段	长度	存储值	说明
  SELECTDB	1字节	常量	表示接下来读入数据库号码
  db_number	1、2或5字节	数字	表示数据库号码
  key_value_pairs	长度不定		数据库所有的键值对数据

1.3.3 key_value_pairs 的文件结构

• key_value_pairs 为 databases 的结构组成部分；有两种类型，一种不带过期时间，一种带过期时间；
• key_value_pairs 部分的逻辑结构：
  

• 各字段含义：

  字段	长度	存储值	说明
  EXPIRETIME_MS	1字节	数值	表示过期时间
  ms	8字节	数值	以毫秒为单位的 UNIX 时间戳
  TYPE	1字节	常量	代表一种对象类型或底层编码
  key	长度不定	字符串对象	表示键对象
  value	长度不定	各种对象	表示值对象

1.3.4 value 的编码

• value 为 key_value_pairs 的结构组成成分；
• value 值对象的结构和长度会根据 TYPE 类型的不同而不同；
• value可以是字符串对象、列表对象、集合对象、哈希表对象、有序集合对象、INTSET编码的集合和ZIPLIST编码的列表、哈希表或有序集合；
• value的格式与编码对应请见 《第3章 对象》1.1 对象的定义；
• 字符串对象的格式与示例：
• 字符串对象可分为：压缩字符串和无压缩字符串两种：

• 列表与集合对象的格式：
  

• 哈希表对象的格式：

• 有序集合对象的格式：

• INTSET 编码集合的格式：

  • 将整数集合转换成字符串即可；

• ZIPLIST编码的列表、哈希表或有序集合的格式：

  • 将压缩列表转换成一个字符串对象，然后再保存到 RDB 文件；

1.4 RDB 文件的示例

• 不包含任何键值对的 RDB 文件：

  REDIS标识	db_version	EOF标识	check_num
  REDIS	0006	377	334 263 c 360 z 334 362 v

• 包含字符串键的 RDB 文件：

  REDIS标识	db_version	SELECTDB	db_number，0 号数据库	TYPE，\0 表示字符串	key	value	EOF标识	check_num
  REDIS	0006	376	\0	\0	003 MSG	005 HELLO	377	207 z = 304 f T L 343

• 包含带有过期时间的字符串键的 RDB 文件：

  REDIS标识	db_version	SELECTDB 切换数据库	EXPIRETIME_MS	ms	TYPE，\0 表示字符串	key	value	EOF标识	check_num
  REDIS	0006	376 \0	374	\ 2 365 336 @ 001 \0 \0	\0	003 MSG	005 HELLO	377	212 231 x 247 252 } 021 306

• 包含一个集合键的 RDB 文件：

  REDIS标识	db_version	SELECTDB 切换数据库	常量 REDIS_RDB_TYPE_SET	key	集合大小	第一个元素	第二个元素	第三个元素	EOF常量	check_num
  REDIS	0006	376 \0	002	004 LANG	003	004 RUBY	004 JAVA	001 C	377	202 312 r 352 346 305 * 023

2 AOF 持久化与 RDB 持久化的区别

• AOF 持久化：保存 Redis 服务器所执行的命令来记录数据库状态；
• RDB 持久化：保存数据库中的键值对来记录数据库状态不同；

3. AOF 持久化

3.1 AOF 持久化的实现

• AOF 持久化功能可分为：追加（append）、文件写入、文件同步（sync）三个步骤；

• AOF 文件中的所有命令都以 Redis 命令请求协议的格式保存；

• 当 AOF 持久化功能打开时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾：

  struct redisServer{
      //...
      //AOF 缓冲区
      sds aof_buf;
  };
  

• AOF 文件的写入与同步依赖事件循环 loop，每次循环主要有三个工作：

  • 处理文件事件：负责接收客户端的命令请求，以及向客户端发送命令回复；
  • 处理时间事件：执行需要定时运行的函数；
  • flushAppendOnlyFile()：考虑是否将 aof_buf 中的内容追加到 AOF 文件中；

• flushAppendOnlyFile() 函数的行为由服务器配置的 appendfsync 选项的值决定，该值有三种不同的行为：

  appendfsync 选项的值	flushAppendOnlyFile 函数的行为	效率与安全性
  always	将 aof_buf 缓冲区中的所有内容写入并同步到 AOF 文件	效率最慢，安全性最高
  everysec	将 aof_buf 缓冲区中的所有内容写入并同步到 AOF 文件，如果上次同步 AOF 文件的事件距离现在超过 1s ，则对再次 AOF 文件进行同步，并且这个同步由一个线程专门负责	效率高
  no	将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，但不对 AOF 文件进行同步，何时同步由操作系统决定	效率最高，安全性最低

3.2 AOF 文件的载入与数据还原

• 服务器创建一个不带网络连接的伪客户（fake client），伪客户端读入并执行 AOF 文件即可；

3.3 AOF 重写

• AOF 重写不需要对现有 AOF 文件进行任何读取、分析或写入操作，而是通过读取服务器当前数据库状态实现；
• AOF 重写功能的实现原理：从数据库读取键现在的值，然后用一条命令记录键值对，代替之前记录这个键值对的多条命令；
• 为了避免执行命令时造成客户端输入缓冲区溢出，重写程序在处理列表、哈希表、集合、有序集合这四种键时，会检查元素数量，超过一定数量（64）时会使用多条命令记录这个键的情况；
  • 这个数量由常量 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 确定；

3.4 AOF 后台重写

• AOF 重写需要解决2个问题：
  • 重写不能阻碍服务器处理客户端请求：使用子进程解决；
  • 子进程在 AOF 重写期间，父进程服务器对数据库状态进行修改，会使服务器当前状态与重写后 AOF 状态不一致：设置AOF 重写缓冲区解决；
• Redis 将 AOF 重写程序放到子进程里执行：
  • 子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理命令请求；
  • 子进程带有服务器进程的数据副本，使用子进程而不是线程，避免使用锁的情况下保证数据安全；

• Redis 服务器设置一个 AOF 重写缓冲区，以保证：

  • AOF 缓冲区的内容会定期被写入和同步到 AOF 文件，对现有 AOF 文件的处理工作如常进行；
  • 从创建子进程开始，服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里；

• 子进程完成 AOF 重写工作后，向父进程发送一个信号，父进程接到信号后调用信号处理函数，执行以下工作：

  • 将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件，此时新 AOF 文件保存的数据库状态将与服务器当前的数据库状态一致；
  • 对新的 AOF 文件进行改名，原子地覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换；

• 只有号处理函数执行时会对服务器进程（父进程）造成阻塞；

最后

新人制作，如有错误，欢迎指出，感激不尽！ 欢迎关注公众号，会分享一些更日常的东西！ 如需转载，请标注出处！