Redis | 第5章 Redis 中的持久化技术《Redis设计与实现》
阅读原文时间:2021年11月28日阅读:1

目录


前言

参考资料:《Redis设计与实现 第二版》;

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

本篇将介绍 Redis 中的持久化技术,主要有两种:RDB持久化AOF持久化


1. RDB 持久化

  • Redis使用 SAVEBGSAVE 命令生成 RDB 文件;

    • SAVE:会阻塞 Redis 服务器进程,直到 RDB 文件创建完毕为止,阻塞期间服务器不能处理任何命令请求;
    • BGSAVE:会派生一个子进程,由指进程负责创建 RDB 文件,父进程继续处理命令请求。BGSAVE 执行期间,会发生以下特殊情况:
      • BGSAVE 命令执行期间,客户端发送 SAVEBGSAVE 命令会被服务器拒绝,防止产生竞争条件。客户端发送 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 设置保存条件

  • 服务器会根据 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.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 文件;
  • 不包含任何键值对的 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 持久化

  • 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 文件进行同步,何时同步由操作系统决定

    效率最高,安全性最低

  • 服务器创建一个不带网络连接的伪客户(fake client),伪客户端读入并执行 AOF 文件即可;

  • AOF 重写不需要对现有 AOF 文件进行任何读取、分析或写入操作,而是通过读取服务器当前数据库状态实现;

  • AOF 重写功能的实现原理:从数据库读取键现在的值,然后用一条命令记录键值对,代替之前记录这个键值对的多条命令

  • 为了避免执行命令时造成客户端输入缓冲区溢出,重写程序在处理列表、哈希表、集合、有序集合这四种键时,会检查元素数量,超过一定数量(64)时会使用多条命令记录这个键的情况;

    • 这个数量由常量 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 确定;
  • AOF 重写需要解决2个问题:

    • 重写不能阻碍服务器处理客户端请求:使用子进程解决;
    • 子进程在 AOF 重写期间,父进程服务器对数据库状态进行修改,会使服务器当前状态与重写后 AOF 状态不一致:设置AOF 重写缓冲区解决;
  • Redis 将 AOF 重写程序放到子进程里执行:

    • 子进程进行 AOF 重写期间,服务器进程(父进程)可以继续处理命令请求;
    • 子进程带有服务器进程的数据副本,使用子进程而不是线程,避免使用锁的情况下保证数据安全;

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

    • AOF 缓冲区的内容会定期被写入和同步到 AOF 文件,对现有 AOF 文件的处理工作如常进行;
    • 从创建子进程开始,服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里;
  • 子进程完成 AOF 重写工作后,向父进程发送一个信号,父进程接到信号后调用信号处理函数,执行以下工作:

    • 将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件,此时新 AOF 文件保存的数据库状态将与服务器当前的数据库状态一致;
    • 对新的 AOF 文件进行改名,原子地覆盖现有的 AOF 文件,完成新旧两个 AOF 文件的替换;
  • 只有号处理函数执行时会对服务器进程(父进程)造成阻塞;


最后

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