RDB 持久化详解

Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以某种形式（数据或命令）从内存保存到硬盘。当下次 Redis 重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。Redis 的持久化机制有两种：

• RDB(Redis Data Base) 内存快照

• AOF(Append Only File) 增量日志

持久化的执行

RDB ( Redis Data Base) 指的是在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB 是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从 Redis 中生成一个快照进行数据的全量备份。是 Redis 默认使用的持久化功能。

SAVE：阻塞服务器并创建 RDB 文件

通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。save 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server 进程阻塞期间，Redis 不能处理任何读写请求，无法对外提供服务。

BGSAVE：以非阻塞方式创建 RDB 文件

通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命令的是，正如该命令的名称一样，background save，后台运行 save。bgsave 命令会使服务器进程 redis-server 生成一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程中，不会阻塞 redis-server 进程对客户端读写请求的处理。

需要注意的是由于执行 BGSAVE 命令需要创建子进程，所以父进程占用的内存数量越大，创建子进程这一操作耗费的时间也会越长，因此 Redis 服务器在执行 BGSAVE 命令时，仍然可能会由于创建子进程而被短暂地阻塞。

通过配置文件自动创建 RDB 文件

自动条件触发的本质仍是 bgsave 命令的执行。只不过是用户通过在配置文件中做相应的设置后，Redis 会根据设置信息自动调用 bgsave 命令执行。

持久化策略按照如下顺序进行：

1. 如果服务器在 60 秒之内，对数据库进行了至少 10000 次修改，则进行持久化。
2. 如果服务器在 300 秒之内，对数据库进行了至少 100 次修改，则进行持久化。
3. 如果服务器在 3600 秒（一小时）之内，对数据库进行了至少 1 次修改，则进行持久化。

查看最近持久化时间

通过 lastsave 命令可以查看最近一次执行持久化的时间，其返回的是一个 Unix 时间戳。

RDB 优化配置

RDB 相关的配置在 redis.conf 文件的 SNAPSHOTTING 部分。

1. save

该配置用于设置快照的自动保存触发条件，即 save point，保存点。该触发条件是在指定时间段内发生了指定次数的写操作。如果不启用 RDB 持久化，只需设置 save 的参数为空串即可：save “”。

2. stop-write-on-bgsave-error

• 翻译：

  然而，如果您已经设置了对 Redis 服务器持久化的正确监控，您可能需要禁用此功能，以便 Redis 能够继续正常工作，即使磁盘、权限等出现问题。

• 解释：

  如果在没有设置持久化正确结果的监控的情况下，启用了 RDB 且最后一次持久化数据失败（磁盘损坏，权限等原因），Redis 就会停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到出故障了。当然，如果 bgsave 命令后来可以正常工作了，Redis 将自动允许再次写入。

3. rdbcompression

• 翻译：

  是否在导出.rdb 数据库文件的时候采用 LZF 压缩字符串和对象？ 默认情况下总是设置成‘yes’，因为它几乎总是一场胜利。 如果你想在存储的子进程中节省一些 CPU 就设置成’no’， 但是这样如果你的 kye/value 是可压缩的，你得到的数据就会很大。

• 解释：

  设置为 yes 时，进行持久化会启用 LZF 算法压缩来压缩字符串对象。虽然压缩 RDB 文件会消耗系统资源和 CPU，降低性能，但可大幅降低磁盘文件的大小，方便保存到磁盘，加速主从集群中从节点的数据同步。

4. rdbchecksum

• 翻译：

  从 RDB 的版本 5 开始 CRC64 校验和被放置在文件的末尾。这使格式更能抵抗损坏，但有一定的性能在保存和加载 RDB 文件时按需付费（约 10%），因此您可以禁用它以获得最大性能。 在禁用校验和的情况下创建的 RDB 文件的校验和为零，这将告诉加载代码跳过检查。

• 解释：

  在存储快照后，我们还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

5. sanitize-dump-payload

• 翻译：

  该配置用于设置在加载 RDB 文件或进行持久化时是否开启对 zipList、listPack 等数据的全面安全检测。该检测可以降低命令处理时发生系统崩溃的可能。其可设置的值有三种选择：

  • no：不检测

  • yes：总是检测

  • clients：只有当客户端连接时检测。排除了加载 RDB 文件与进行持久化时的检测。

  默认值本应该是 clients，但其会影响 Redis 集群的工作，所以默认值为 no，不检测。

6. dbfilename

指定 RDB 文件的默认名称，默认为 dump.rdb。

7. rdb-del-sync-files

主从复制时，是否删除用于同步的从机上的 RDB 文件。默认是 no，不删除。不过需要注意，只有当从机的 RDB 和 AOF 持久化功能都未开启时才生效。

8. dir

设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

RDB 文件结构

rdb 文件整体上可分为三个区域：头信息区、数据区、尾信息区。

1. 头部信息区

1. 魔数

   以 ascii 码 “REDIS” 开头。用来验证当前文件的格式。类似 java 程序编译后的 class 文件，以 “CAFEBABE” 魔数开头，寓意 java 和 cafe 的千丝万缕的关系。

2. RDB version

   表示 RDB 文件的版本。并且高版本 redis 可以 100% 向后兼容加载旧版 rdb 文件。版本信息使用 4 个字节表示。 如：30 30 30 37 转换为 ascii 码 00 00 00 07，代表 rdb version 文件为第 7 版。

3. AUX metadata

   可以存放多组 key-value，用来表示对应元信息。每一对 key-value，都以 0xFA 开头。key 和 value 均采用 rdb 字符串编码方法。

   默认元信息列表：

   • redis-ver：redis 版本信息。
   • redis-bits：输出 rdb 文件机器的位数，64bit 或 32 bit。
   • ctime：rdb 文件创建时间。
   • used-mem：rdb 加载到内存中的内存使用量。

2. 数据区

1. SELECTDB

   常量的长度为 1 字节。当读入程序遇到这个值的时候， 它知道接下来要读入的将是一个数据库号码。

2. db_number

   保存着一个数据库号码， 根据号码的大小不同， 这个部分的长度可以是 1 字节、 2 字节或者 5 字 B 节。 当程序读入 db_number 部分之后， 服务器会调用 SELECT 命令， 根据读入的数据库号码进行数据库切换， 使得之后读入的键值对可以载入到正确的数据库中。

3. key_value_pairs

   保存了数据库中的所有键值对数据。

   不带过期时间的键值对：

   • TYPE 记录了 value 的类型， 长度为 1 字节， 值可以是以下常量的其中一个：

     • REDIS_RDB_TYPE_STRING
     • REDIS_RDB_TYPE_LIST
     • REDIS_RDB_TYPE_SET
     • REDIS_RDB_TYPE_ZSET
     • REDIS_RDB_TYPE_HASH
     • REDIS_RDB_TYPE_LIST_ZIPLIST
     • REDIS_RDB_TYPE_SET_INTSET
     • REDIS_RDB_TYPE_ZSET_ZIPLIST
     • REDIS_RDB_TYPE_HASH_ZIPLIST

     以上列出的每个 TYPE 常量都代表了一种对象类型或者底层编码， 当服务器读入 RDB 文件中的键值对数据时， 程序会根据 TYPE 的值来决定如何读入和解释 value 的数据。

   • key 总是一个字符串对象， 它的编码方式和 REDIS_RDB_TYPE_STRING 类型的 value 一样。 根据内容长度的不同， key 的长度也会有所不同。

   • value 会根据 TYPE 类型的不同， 以及保存内容长度的不同， 保存 value 的结构和长度也会有所不同。

   带有过期时间的键值对：

   • EXPIRETIME_MS 常量的长度为 1 字节， 它告知读入程序， 接下来要读入的将是一个以毫秒为单位的过期时间。
   • ms 是一个 8 字节长的带符号整数， 记录着一个以毫秒为单位的 UNIX 时间戳， 这个时间戳就是键值对的过期时间。
   • 带有过期时间的键值对中的 TYPE 、 key 、 value 三个部分的意义， 和前面介绍的不带过期时间的键值对的 TYPE 、 key 、 value 三个部分的意义完全相同。

3. 尾信息区

该区域最为简单。固定使用 9 byte。第一 byte 为 0xFF ，之后固定跟着 8 byte 用于 crc64 校验。该校验码采用 crc-64-jones 算法生成，用于校验 rdb 文件的合法性。

RDB 持久化过程

RDB 持久化方案进行备份时，Redis 会单独 fork 一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的 RDB 文件。在整个持久化过程中，主进程（为客户端提供服务的进程）不参与 IO 操作，这样能确保 Redis 服务的高性能，RDB 持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。下面展示 RDB 持久化流程：

关键执行步骤如下

1. Redis 父进程首先判断：当前是否在执行 save，或 bgsave/bgrewriteaof 的子进程，如果在执行则 bgsave 命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。

2. 父进程执行 fork 操作创建子进程，这个过程中父进程是阻塞的，Redis 不能执行来自客户端的任何命令。父进程 fork 后，bgsave 命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令。

3. 子进程进程对内存数据生成快照文件。

4. 父进程在此期间接收的新的写操作，使用 COW 机制写入。

5. 子进程完成快照写入，替换旧 RDB 文件，随后子进程退出。

在生成 RDB 文件的步骤中，在同步到磁盘和持续写入这个过程是如何处理数据不一致的情况呢？生成快照 RDB 文件时是否会对业务产生影响？

Fork 子进程的作用

上面说到了 RDB 持久化过程中，主进程会 fork 一个子进程来负责 RDB 的备份，这里简单介绍一下 fork：

• Linux 操作系统中的程序，fork 会产生一个和父进程完全相同的子进程。子进程与父进程所有的数据均一致，但是子进程是一个全新的进程，与原进程是父子进程关系。

• 出于效率考虑，Linux 操作系统中使用 COW(Copy On Write)写时复制机制，fork 子进程一般情况下与父进程共同使用一段物理内存，只有在进程空间中的内存发生修改时，内存空间才会复制一份出来。

在 Redis 中，RDB 持久化就是充分的利用了这项技术，Redis 在持久化时调用 glibc 函数 fork 一个子进程，全权负责持久化工作，这样父进程仍然能继续给客户端提供服务。fork 的子进程初始时与父进程（Redis 的主进程）共享同一块内存；当持久化过程中，客户端的请求对内存中的数据进行修改，此时就会通过 COW (Copy On Write) 机制对数据段页面进行分离，也就是复制一块内存出来给主进程去修改。

数据丢失情况分析

save 命令数据丢失

• 因为服务器最后一次成功执行 SAVE 命令是在 T6，所以服务器创建出的 RDB 文件将包含键 k1 至键 k4 在内的数据，服务器在重启时将使用这个 RDB 文件进行数据恢复
• 因为服务器在 T6 之后创建了键 k5 和键 k6，并在之后出现停机，所以当服务器重启时，键 k5、k6 的数据将丢失，而键 k1 至键 k4 的数据将被恢复。

bgsave 命令数据丢失

• 因为 T7 创建的新 RDB 文件尚未完成，所以服务器在停机之后将使用 T5 成功创建的 RDB 文件进行数据恢复。
• 虽然服务器现有的 RDB 文件是在 T5 成功创建的，但由于这个文件是在 T3 开始创建的，所以它只包含了 T3 之前的数据，即键 k1 和键 k2 的数据。
• 基于上述原因，当服务器重启时，只有键 k1 和键 k2 的数据会被恢复，而键 k3 至键 k6 的数据则会丢失。

RDB 的优缺点

优点：

• 存储紧凑，节省内存空间。

• 恢复速度非常快。

• 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）。

缺点：

• 容易丢失数据，容易丢失两次快照之间 Redis 服务器中变化的数据。
• RDB 通过 fork 子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。