07 Redis之持久化(RDB(Redis DataBase) + 写时复制 + AOF(Append Only File)+混合持久化)

4 Redis持久化

Redis 是一个内存数据库，然而内存中的数据是不持久的，若主机宕机或 Redis 关机重启，则内存中的数据全部丢失。

当然，这是不允许的。Redis 具有持久化功能，其会按照设置以快照或操作日志的形式将数据持久化到磁盘。

4.1 持久化基本原理

在这里插入图片描述
Redis 持久化也称为钝化，是指将内存中数据库的状态描述信息保存到磁盘中。
只不过是不同的持久化技术，对数据的状态描述信息是不同的，生成的持久化文件也是不同的。但它们的作用都是相同的：避免数据意外丢失。

通过手动方式，或自动定时方式，或自动条件触发方式，将内存中数据库的状态描述信息写入到指定的持久化文件中。当系统重新启动时，自动加载持久化文件，并根据文件中数据库状态描述信息将数据恢复到内存中，这个数据恢复过程也称为激活。

这个钝化与激活的过程就是 Redis 持久化的基本原理。

不过从以上分析可知，对于 Redis 单机状态下，无论是手动方式，还是定时方式或条件触发方式，都存在数据丢失问题：在尚未手动/自动保存时发生了 Redis 宕机状况，那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式，其数据的丢失率也是不同的。

4.2 Redis默认RDB持久化

Redis默认使用RDB方式进行持久化,
即若不进行任何配置, 那么每次开机系统会自动加载Redis安装目录下的dump.rdb文件, 复原数据库到上一个记录点

同时 , 尽管RDB为Redis的默认持久化方式，但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启，此时系统会优先使用 AOF 方式做持久化，即加载AOF持久化文件进行数据库复原.

在这里插入图片描述

4.3 RDB 持久化

RDB(Redis DataBase)，是指将内存中某一时刻的数据快照全量写入到指定的 rdb 二进制文件的持久化技术。

RDB 持久化默认是开启的。当 Redis 启动时会自动读取 RDB 快照文件，将数据从硬盘载入到内存，以恢复 Redis 关机前的数据库状态。

4.3.1 RDB持久化的执行

RDB 持久化的执行有三种方式：手动 SAVE 命令、手动 BGSAVE 命令，与自动条件触发。

4.3.1.1 手动SAVE命令

执行 SAVE 命令可立即进行一次持久化保存。

SAVE 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。即在执行SAVE命令的过程中 , Redis不能处理任何读写请求，无法对外提供服务。

4.3.1.2 手动BGSAVE命令

background save，后台运行 save。

执行BGSAVE 命令会使服务器进程 redis-server 生成一个子进程，由该子进程负责完成保存过程。

在子进程进行保存过程中，不会阻塞 redis-server 进程对客户端读写请求的处理。

4.3.1.3 自动条件触发

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

4.3.1.4 LASTSAVE查看最近一次什么时候执行过持久化

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

4.3.2 RDB优化配置

RDB 相关的配置在 redis.conf 文件的 SNAPSHOTTING 部分。
在这里插入图片描述

4.3.2.1 sava

在这里插入图片描述
该配置用于设置快照的自动保存触发条件，即 save point，保存点。该触发条件是在指定时间段内发生了指定次数的写操作。除非另有规定，默认情况下持久化条件为 save 3600 1 300 100 60 10000。其等价于以下三条：

save 3600 1 # 在 3600 秒(1 小时)内发生 1 次写操作
save 300 100 # 在 300 秒(5 分钟)内发生 100 次写操作
save 60 10000 # 在 60 秒(1 分钟)内发生 1 万次写操作

如果不启用 RDB 持久化，只需设置 save 的参数为空串即可：save “”。

Redis7之前 , 自动触发条件为:
在这里插入图片描述

4.3.2.2 stop-write-on-bgsave-error

在这里插入图片描述默认情况下，如果 RDB 快照已启用（至少一个保存点），且最近的 bgsave 命令失败，Redis将停止接受写入。

这样设置是为了让用户意识到数据没有正确地保存到磁盘上，否则很可能没有人会注意到，并会发生一些灾难。

当然，如果 bgsave 命令后来可以正常工作了，Redis将自动允许再次写入。

4.3.2.3 rdbcompression

在这里插入图片描述当进行持久化时启用 LZF 压缩字符串对象。
虽然压缩 RDB 文件会消耗系统资源，降低性能，但可大幅降低文件的大小，方便保存到磁盘，加速主从集群中从节点的数据同步。

4.3.2.4 rdbchecksum

在这里插入图片描述从 RDB5 开始，RDB 文件的 CRC64 校验和就被放置在了文件末尾。这使格式更能抵抗 RDB文件的损坏，但在保存和加载 RDB 文件时，性能会受到影响（约 10%），因此可以设置为 no禁用校验和以获得最大性能。在禁用校验和的情况下创建的 RDB 文件的校验和为零，这将告诉加载代码跳过校验检查。默认为 yes，开启了校验功能。

4.3.2.5 sanitize-dump-payload

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

no：不检测
yes：总是检测
clients：只有当客户端连接时检测。排除了加载 RDB 文件与进行持久化时的检测。默认值本应该是 clients，但其会影响 Redis 集群的工作，所以默认值为 no，不检测。

4.3.2.6 dbfilename

在这里插入图片描述
指定 RDB 文件的默认名称，默认为 dump.rdb。

4.3.2.7 rdb-del-sync-files

在这里插入图片描述
主从复制时，是否删除用于同步的从机上的 RDB 文件。
默认是 no，不删除。
不过需要注意，只有当从机的 RDB 和 AOF 持久化功能都未开启时, 这个设置才会被系统检测并应用。

4.3.2.8 dir

在这里插入图片描述指定 RDB 与 AOF 文件的生成目录。默认为 Redis 安装根目录。

4.3.3 RDB文件结构

RDB 持久化文件 dump.rdb 整体上有五部分构成：
在这里插入图片描述
（1） SOF
SOF 是一个常量，一个字符串 REDIS，仅包含这五个字符，其长度为 5。用于标识 RDB文件的开始，以便在加载 RDB 文件时可以迅速判断出文件是否是 RDB 文件。

（2） rdb_version
这是一个整数，长度为 4 字节，表示 RDB 文件的版本号。

（3） EOF
EOF 是一个常量，占 1 个字节，用于标识 RDB 数据的结束，校验和的开始。

（4） check_sum
校验和 check_sum 用于判断 RDB 文件中的内容是否出现数据异常。其采用的是 CRC 校验算法。
CRC 校验算法：
在持久化时，先将 SOF、rdb_version 及内存数据库中的数据快照这三者的二进制数据拼接起来，形成一个二进制数（假设称为数 a），然后再使用这个 a 除以校验和 check_sum，此时可获取到一个余数 b，然后再将这个 b 拼接到 a 的后面，形成 databases。

在加载时，需要先使用 check_sum 对 RDB 文件进行数据损坏验证。

验证过程：只需将RDB 文件中除 EOF 与 check_sum 外的数据除以 check_sum。只要除得的余数不是 0，就说明文件发生损坏。当然，如果余数是 0，也不能肯定文件没有损坏。

这种验证算法，是数据损坏校验，而不是数据没有损坏的校验。
即: 除得余数不为0, 一定损坏 ; 除得余数不为0 , 也未必完好

（5） databases
在这里插入图片描述
databases 部分是 RDB 文件中最重要的数据部分，其可以包含任意多个非空数据库。而每个 database 又是由三部分构成：

SODB：是一个常量，占 1 个字节，用于标识一个数据库的开始。
db_number：数据库编号。
key_value_pairs：当前数据库中的键值对数据。

进一步的 , 对于每一个键值对, 还分为带过期时间和不带的版本
在这里插入图片描述

4.3.4 RDB持久化过程

在这里插入图片描述
对于 Redis 默认的 RDB 持久化，在进行 bgsave 持久化时，redis-server 进程会 fork 出一个 bgsave 子进程，由该子进程以异步方式负责完成持久化。而在持久化过程中，redis-server进程不会阻塞，其会继续接收并处理用户的读写请求。

bgsave 子进程的详细工作原理如下：

由于子进程可以继承父进程的所有资源，且父进程不能拒绝子进程的继承权。所以， bgsave 子进程有权读取到 redis-server 进程写入到内存中的用户数据，使得将内存数据持久化到 dump.rdb 成为可能。
bgsave 子进程在持久化时首先会将内存中的全量数据 copy 到磁盘中的一个 RDB 临时文件，copy 结束后，再将该文件 rename 为 dump.rdb，替换掉原来的同名文件。
不过，在进行持久化过程中，如果 redis-server 进程接收到了用户写请求，则系统会将内存中发生数据修改的物理块 copy 出一个副本。等内存中的全量数据 copy 结束后，会再将副本中的数据 copy 到 RDB 临时文件。这个副本的生成是由于 Linux 系统的写时复制技术（Copy-On-Write）实现的。

4.3.5 写时复制(Copy-On-Write）

原本在 Unix 系统中，当一个主进程通过 fork()系统调用创建子进程后，内核进程会复制主进程的整个内存空间中的数据，然后分配给子进程。这种方式存在的问题有以下几点：

这个过程非常耗时
这个过程降低了系统性能
如果主进程修改了其内存数据，子进程副本中的数据是没有修改的。即出现了数据冗余，而冗余数据最大的问题是数据一致性无法保证。

现代的 Linux 则采用了更为有效的方式：写时复制。

子进程会继承父进程的所有资源，其中就包括主进程的内存空间。即子进程与父进程共享内存。只要内存被共享，那么该内存就是只读的（写保护的）。而写时复制则是在任何一方需要写入数据到共享内存时都会出现异常，此时内核进程就会将需要写入的数据 copy 出一个副本写入到另外一块非共享内存区域。

4.4 AOF持久化

AOF，Append Only File，是指 Redis 将每一次的写操作都以日志的形式记录到一个 AOF文件中的持久化技术。
当需要恢复内存数据时，将这些写操作重新执行一次，便会恢复到之前的内存数据状态。

4.4.1 AOF基础配置

4.4.1.1 AOF的开启

在这里插入图片描述
默认情况下 AOF 持久化是没有开启的，通过修改配置文件中的 appendonly 属性为 yes可以开启。

4.4.1.2 文件名配置(Redis7新变化)

在这里插入图片描述
Redis 7 在这里发生了重大变化。原来只有一个 appendonly.aof 文件，现在具有了三类多个文件：

基本文件：可以是 RDF 格式也可以是 AOF 格式。其存放的内容是由 RDB 转为 AOF 当时内存的快照数据。该文件可以有多个。
增量文件：以操作日志形式记录转为 AOF 后的写入操作。该文件可以有多个。
清单文件：用于维护 AOF 文件的创建顺序，保障激活时的应用顺序。该文件只有一个。

4.4.1.3 混合持久化开启

在这里插入图片描述对于基本文件可以是 RDF 格式也可以是 AOF 格式。通过 aof-use-rdb-preamble 属性可以选择。其默认值为 yes，即默认 AOF 持久化的基本文件为 rdb 格式文件，也就是默认采用混合式持久化。后续对混合持久化有详细介绍.

4.4.1.4 配置AOF持久化文件存放位置

在这里插入图片描述

4.4.2 AOF文件格式

AOF 文件包含三类文件：基本文件、增量文件与清单文件。其中基本文件一般为 rdb 格式，在前面已经研究过了。下面就来看一下增量文件与清单文件的内容格式。

4.4.2.1 Redis协议(.aof文件)

增量文件扩展名为.aof，采用 AOF 格式。AOF 格式其实就是 Redis 通讯协议格式，AOF持久化文件的本质就是基于 Redis 通讯协议的文本，将命令以纯文本的方式写入到文件中。

Redis 协议规定，Redis 文本是以行来划分，每行以\r\n 行结束。每一行都有一个消息头，以表示消息类型。

4.4.3 rewrite机制

AOF 持久化是通过保存被执行的写命令来记录数据库状态的，随着写入命令的不断增加，AOF 文件中的内容会越来越多，文件的体积也会越来越大。

如果不加以控制，体积过大的 AOF 文件可能会对 Redis 服务器、甚至整个宿主机造成影响，并且 AOF 文件的体积越大，使用 AOF 文件来进行数据还原所需的时间就越多。

举个例子，如果你对一个计数器调用了 100 次 INCR ，那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录。

然而在实际上，只使用一条 SET 命令已经足以保存计数器的当前值了，其余 99 条记录实际上都是多余的。

4.4.3.1 什么是rewrite

因此, AOF 重写就是 : 在不打断服务端处理请求的情况下，对 AOF 文件进行重建（rebuild）。这个新的 AOF 文件包含重建当前数据集所需的最少命令。
具体过程是遍历所有数据库的所有键，从数据库读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。

当 Rewrite 开启后，主进程 redis-server创建出一个子进程 bgrewriteaof，由该子进程完成 rewrite 过程。其首先对现有 aof 文件进行rewrite 计算，将计算结果写入到一个临时文件，写入完毕后，再 rename 该临时文件为原 aof文件名，覆盖原有文件。

4.4.3.2 rewrite计算(rewrite策略)

rewrite计算(rewrite策略)遵循的原则

读操作命令不写入文件
无效命令不写入文件
过期数据不写入文件
多条命令合并写入文件

4.4.3.3 手动开启rewrite

在这里插入图片描述

4.4.3.4 条件触发开启rewrite

由于 Rewrite 过程是一个计算过程，需要消耗大量系统资源，会降低系统性能。
所以，Rewrite 过程并不是随时随地任意开启的，而是通过设置一些条件，当满足条件后才会启动，以降低对性能的影响。
在这里插入图片描述

4.4.4 AOF优化配置

4.4.4.1 appendfsync

在这里插入图片描述

4.4.5 AOF持久化过程

在这里插入图片描述

Redis 接收到的写操作命令并不是直接追加到磁盘的 AOF 文件的，而是将每一条写命令按照 redis 通讯协议格式暂时添加到 AOF 缓冲区 aof_buf。
根据设置的数据同步策略(appendfsync)，当同步条件满足时，再将缓冲区中的数据一次性写入磁盘的AOF 文件，以减少磁盘 IO 次数，提高性能。
当磁盘的 AOF 文件大小达到了 rewrite 条件时，redis-server 主进程会 fork 出一个子进程bgrewriteaof，由该子进程完成 rewrite 过程。
子进程 bgrewriteaof 首先对该磁盘 AOF 文件进行 rewrite 计算，将计算结果写入到一个临时文件，全部写入完毕后，再 rename 该临时文件为磁盘文件的原名称，覆盖原文件。
如果在 rewrite 过程中又有写操作命令追加，那么这些数据会暂时写入 aof_rewrite_buf缓冲区。等将全部 rewrite 计算结果写入临时文件后，会先将 aof_rewrite_buf 缓冲区中的数据写入临时文件，然后再 rename 为磁盘文件的原名称，覆盖原文件。

4.5 混合持久化

在这里插入图片描述

为什么要采用混合持久化?

重启Redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF日志恢复。
但是AOF日志性能相对RDB来说要慢很多，这样在Redis实例很大的情况下，启动需要花费很长的时间。

当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件，然后再将 AOF 重写缓冲区（aof_rewrite_buf_blocks）的增量命令以 AOF 方式写入到文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

4.5.1 开启混合持久化

# 同时开启RDB和AOF持久化
save 900 1
save 300 10
save 60 10000

appendonly yes

aof‐use‐rdb‐preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理

并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

于是在Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放，因此重启效率大幅得到提升