Redis7中的持久化技术RDB和AOF的详细解释说明

前置知识

官网关于持久化的说明

Redis 是一个内存数据库，所以其运行效率非常高。但也存在一个问题：内存中的数据是不持久的，若主机宕机或 Redis 关机重启，则内存中的数据全部丢失。当然，这是不允许的。Redis 具有持久化功能，其会按照设置以快照或操作日志的形式将数据持久化到磁盘。
根据持久化使用技术的不同，Redis 的持久化分为两种：RDB 与 AOF。其中快照的方式是RDB， 操作日志的方式是AOF

持久化原理

使用不同的持久化技术，对数据状态的描述信息是不一样的，生成的持久化文件也是不同的。但是，他们的作用都是相同的：都是避免数据的意外丢失。

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

不过从以上进行分析，对于Redis单机的情况下，无论是手动方式，还是定时方式还是通过触发条件触发的方式，都会存在着数据丢失的问题：

在尚未手动/自动保存时发生了 Redis 宕机状况，那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式，其数据的丢失率也是不同的。

RDB是默认的持久化方式，但Redis允许RDB 与AOF两种持久化技术同时开启，此时系统会使用 AOF 方式做持久化，即 AOF 持久化技术的优先级要更高。同样的道理，两种技术同时开启状态下，系统启动时若两种持久化文件同时存在，则优先加载 AOF持久化文件。

RDB持久化

Redis DataBase （RDB）, 就是将内存中某一时刻的数据全量写入到指定的RDB文件中（在redis.conf有配置）的持久化技术。是默认开启的，当 Redis 启动时会自动读取 RDB 快照文件，将数据从硬盘载入到内存，以恢复 Redis 关机前的数据库状态。对于RDB的保存，有两种方式可能会进行保存：1. 自动触发 2. 手动触发

1. 自动触发
   通过配置文件中配置,触发的条件
2. 手动触发
   通过命令save, bgsave

如何禁止使用RDB的方式来保存快照：

1. 动态所有停止RDB保存规则的方法： redis-cli config set save “”
2. 快照禁用(直接在redis.conf的配置文件中加上这一个配置项)
   

RDB优化配置项

• save <seconds> <changes>
  修改RDB文件保存触发的条件，表示在seconds中如果进行了changes次修改，就会触发保存
• dbfilename
  表示RDB文件保存时，所用的文件名
• dir
  RDB备份文件保留的路径
• stop-writes-on-bgsave-error
  默认就是yes, 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现何控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的请求。
• rdbcompression
  默认就是yes,对于存储在磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
• rdbchecksum
  默认yes,在存储快照后，还可以让Redis使用CRC64算法来进行数据校验，但是这样作会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
• rdb-del-sync-files
  在没有持久化的情况下删除复制中使用的RDB文件启用。默认情况下是no，此选项是禁用的。

RDB文件格式

RDB 持久化文件dump.rdb整体上有五部分构成：

• SOF
  SOF 是一个常量，一个字符串 REDIS，仅包含这五个字符，其长度为 5。用于标识 RDB文件的开始，以便在加载 RDB 文件时可以迅速判断出文件是否是 RDB 文件。和JVM虚拟机一样，都是判别当前文件是不是指定的文件。
• rdb_version
  长度是4个字节，表示的是当前RDB的版本号。
• EOF
  EOF是一个常量，占1个字节，用于表示RDB文件的结束，校验和的开始。
• check_sum
  校验和 check_sum 用于判断 RDB 文件中的内容是否出现数据异常。其采用的是 CRC 校验算法。
• databases
  这一部分是重点
  
  databases部分是RDB 文件中最重要的数据部分，其可以包含任意多个非空数据库。而每个 database 又是由三部分构成：
  • SODB： 是一个常量，占用一个字节，用于标识一个数据库的开始
  • db_number ：数据库编号
  • key_value_pairs： 当前数据库的健值对
    
    每个 key_value_pairs 又由很多个用于描述键值对的数据构成。
    • VALUE_TYPE: 是一个常量，占 1 个字节，用于标识该键值对中 value 的类型
    • EXPIRETIME_UNIT: 是一个常量，占 1 个字节，用于标识过期时间的单位是秒还是毫秒
    • time: 是当前key-value的过期的时间。

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实现的

---

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

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

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

---

RDB总结

AOF持久化

一定是RDB的数据持久化方式有部分的问题，才会出现AOF的持久化方式 。

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

默认情况下，Redis是没有开启AOF(appond only file)的，开始AOF功能需要设置配置: appendonly yes

AOF的工作流程

流程：

• client作为命令的来源有多个源头，源源不断的请求命令。
• 在这些命令到达Redis Server之后并不是直接写入到AOF文件，而是将其其中这些命令先放入到AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一个区域，避免频繁的IO操作。
• AOF缓冲会根据AOF同步文件的三种写回策略将命令写入到磁盘上的AOF文件中。
• AOF内容的不断增加会有文件膨胀，会根据规则进行命令的合并（AOF重写），从而起到AOF压缩的目的。

三种写回策略会在后问配置优化项中提，主要是在Redis.conf中配置appendfsync，一共有三种always, no, everysec

AOF 详细的持久化过程如下：

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

对于同步策略和是否达到rewrite条件都是自己在redis.conf中配置的

AOF中的rewirte机制

随着使用时间的推移，AOF 文件会越来越大。为了防止 AOF 文件由于太大而占用大量的磁盘空间，降低性能，Redis 引入了 Rewrite 机制来对 AOF 文件进行压缩。

rewrite

所谓 Rewrite 其实就是对 AOF 文件进行重写整理。当 Rewrite 开启后，主进程 redis-server创建出一个子进程 bgrewriteaof，由该子进程完成 rewrite 过程。其首先对现有 aof 文件进行rewrite 计算，将计算结果写入到一个临时文件，写入完毕后，再 rename 该临时文件为原 aof文件名，覆盖原有文件。
Rewite计算（Rewrite 计算也称为 rewrite 策略） , 需要遵守的是：

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

如何手动的开启Rewrite。 和RDB一样，也有两种方式，一种是手动的，一种是设置条件自动触发。

1. 手动开启：
   

该命令会使主进程 redis-server 创建出一个子进程 bgrewriteaof，由该子进程完成 rewrite过程。而在 rewrite 期间，redis-server 仍是可以对外提供读写服务的。

2. 设置条件自动触发
   由于 Rewrite 过程是一个计算过程，需要消耗大量系统资源，会降低系统性能。所以，Rewrite 过程并不是随时随地任意开启的，而是通过设置一些条件，当满足条件后才会启动，以降低对性能的影响。
   

   • auto-aof-rewrite-percentage
     指定 Redis 重写 AOF 文件的条件，默认为 100，它会对比上次生成的 AOF 文件大小。如果当前 AOF 文件的增长量大于上次 AOF 文件的 100%，就会触发重写操作；如果将该选项设置为 0，则不会触发重写操作。
   • auto-aof-rewrite-min-size
     开启 rewrite 的 AOF 文件最小值，默认 64M。该值的设置主要是为了防止小 AOF 文件被 rewrite，从而导致性能下降。

总的原理总结如下：

Redis会记住最新Rewrite后的AOF文件大小作为基本，如果从主机启动之后就没有发生过重写，则基本大小使用启动时AOF的大小。如果当前AOF文件大雨基本大小文件中配置文件指定的百分比阈值，并且当前AOF文件大与配置文件指定的最小阈值，就会出发Rewrite.

rewrite的操作： 如果是满足rewrite的策略，就会按照上图所示的步骤去进行重写。

• bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行
• 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞
• 子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失
• 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件
• 使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写

AOF文件格式

AOF 文件包含三类文件：基本文件、增量文件与清单文件。其中基本文件一般为 rdb 格式，在前面已经研究过了。下面就来看一下增量文件与清单文件的内容格式 ：Redis7.0 新特性（超详细）

看看有关于Redis协议
增量文件扩展名为.aof，采用 AOF 格式。AOF 格式其实就是 Redis 通讯协议格式，AOF持久化文件的本质就是基于 Redis 通讯协议的文本，将命令以纯文本的方式写入到文件中。Redis 协议规定，Redis 文本是以行来划分，每行以\r\n 行结束。每一行都有一个消息头，以表示消息类型。消息头由六种不同的符号表示，其意义如下：

查看AOF文件

(1) 打开appendonly.aof.1.incr.aof文件，可以看到如下格式内容:

(2) 打开清单文件
打开清单文件 appendonly.aof.manifest，查看其内容如下

该文件首先会按照 seq 序号列举出所有基本文件，基本文件 type 类型为 b，然后再按照seq 序号再列举出所有增量文件，增量文件 type 类型为 i
对于 Redis 启动时的数据恢复，也会按照该文件由上到下依次加载它们中的数据

AOF优化配置项

• appendfsync
  当客户端提交写操作命令后，该命令就会写入到 aof_buf 中，而 aof_buf 中的数据持久化到磁盘 AOF 文件的过程称为数据同步。何时将 aof_buf 中的数据同步到 AOF 文件？采用不同的数据同步策略，同时的时机是不同的，有三种策略：
  • always
    写操作命令写入 aof_buf 后会立即调用 fsync()系统函数，将其追加到 AOF 文件。该策略效率较低，但相对比较安全，不会丢失太多数据。最多就是刚刚执行过的写操作在尚未同步时出现宕机或重启，将这一操作丢失
  • no
    写操作命令写入 aof_buf 后什么也不做，不会调用 fsync()函数。而将 aof_buf 中的数据同步磁盘的操作由操作系统负责。Linux 系统默认同步周期为 30 秒。效率较高。
  • everysec
    默认策略。写操作命令写入 aof_buf 后并不直接调用 fsync()，而是每秒调用一次 fsync()系统函数来完成同步。该策略兼顾到了性能与安全，是一种折中方案。
• no-appendfsync-on-rewrite
  该属性用于指定，当 AOF fsync 策略设置为 always 或 everysec，当主进程创建了子进程正在执行 bgsave 或 bgrewriteaof 时，主进程是否不调用 fsync()来做数据同步。设置为 no，双重否定即肯定，主进程会调用 fsync()做同步。而 yes 则不会调用 fsync()做数据同步。
  如果调用 fsync()，在需要同步的数据量非常大时，会阻塞主进程对外提供服务，即会存在延迟问题。如果不调用 fsync()，则 AOF fsync 策略相当于设置为了 no，可能会存在 30 秒数据丢失的风险。
• aof-rewrite-incremental-fsync
  当 bgrewriteaof 在执行过程也是先将 rewrite 计算的结果写入到了 aof_rewrite_buf 缓存中，然后当缓存中数据达到一定量后就会调用 fsync()进行刷盘操作，即数据同步，将数据写入到临时文件。该属性用于控制 fsync()每次刷盘的数据量最大不超过 4MB。这样可以避免由于单次刷盘量过大而引发长时间阻塞。
• aof-load-truncated
  在进行 AOF 持久化过程中可能会出现系统突然宕机的情况，此时写入到 AOF 文件中的最后一条数据可能会不完整。当主机启动后，Redis 在 AOF 文件不完整的情况下是否可以启
  动，取决于属性 aof-load-truncated 的设置。其值为：
  yes：AOF 文件最后不完整的数据直接从 AOF 文件中截断删除，不影响 Redis 的启动。
  no：AOF 文件最后不完整的数据不可以被截断删除，Redis 无法启动。
• aof-timestamp-enabeld
  该属性设置为 yes 则会开启在 AOF 文件中增加时间戳的显示功能，可方便按照时间对数据进行恢复。但该方式可能会与 AOF 解析器不兼容，所以默认值为 no，不开启

AOF+RDB混用

如果是两个缓存都进行混用的话，优先加载的是AOF如何开启混合模式： 在配置文件中将配置项：aof-use-rdb-preamble yes


通过这种模式： RDB镜像做的是全量持久化 ，AOF做的是增量持久化。

纯缓存模式

直接将save “” 禁用rdb，或者是 appendonly no 就可以关闭RDB模式和AOF文件的持久化方式。

对比和技术选型建议

	优势	劣势
RDB	RDB 文件较小, 数据恢复较快	数据安全性较差,写时复制会降低性能,RDB 文件可读性较差
AOF	数据安全性高，AOF 文件可读性强	AOF 文件较大，写操作会影响性能，数据恢复较慢

推荐使用的用法：

• 官方推荐使用 RDB 与AOF混合式持久化。
• 若对数据安全性要求不高，则推荐使用纯 RDB 持久化方式。
• 不推荐使用纯 AOF 持久化方式。
• 若 Redis 仅用于缓存，则无需使用任何持久化技术。

---

最难不过坚持