Redis的持久化详解

- 一、Redis的持久化
- 二、RDB（Redis DataBase）
- - 1、RDB快照原理
  - 2、RDB配置
  - 3、redis.conf 其他一些配置
  - 4、RDB的备份恢复
  - 5、RDB优缺点
- 三、AOF（Append Of File）
- - 1、AOF原理
  - 2、AOF配置
  - 3、AOF的备份恢复
  - 4、重写流程
  - 5、AOF优缺点
- 四、AOF和RDB对比
- 五、AOF和RDB官网建议
- 六、Redis 4.0 混合持久化
- - 1、混合持久化原理
  - 2、混合持久化配置
  - 3、混合持久化优缺点

一、Redis的持久化

Redis是一个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务或者断电会丢失。Redis的数据也支持写到硬盘中，这个过程就叫做持久化。

Redis提供了2种不同形式的持久化方式：

RDB（Redis DataBase） ：简而言之，就是在指定的时间间隔内，定时的将 redis 存储的数据生成Snapshot快照并存储到磁盘等介质上；
AOF（Append Of File） ：将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

RDB（Redis DataBase）：redis备份默认方式

同时允许使用两种方式： 其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。

可以选择关闭持久化： 如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。

官网介绍：

https://redis.com.cn/redis-persistence.html
https://redis.com.cn/topics/persistence.html#redis

二、RDB（Redis DataBase）

1、RDB快照原理

我们知道 Redis 是单线程程序，这个线程要同时负责多个客户端套接字的并发读写操作和内存数据结构的逻辑读写。

在服务线上请求的同时，Redis 还需要进行内存快照，内存快照要求 Redis 必须进行文件 IO 操作，这意味着单线程同时在服务线上的请求还要进行文件 IO 操作，文件 IO 操作会严重拖垮服务器请求的性能。还有个重要的问题是为了不阻塞线上的业务，就需要边持久化边响应客户端请求。持久化的同时，内存数据结构还在改变，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它给删掉了，还没持久化完呢，这要怎么搞？

Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化，这个机制很有意思，也很少人知道。多进程 COW 也是鉴定程序员知识广度的一个重要指标。

fork(多进程)

Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。这时你可以将父子进程想像成一个连体婴儿，共享身体。这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。

子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

随着父进程修改操作的持续进行，越来越多的共享页面被分离出来，内存就会持续增长。但是也不会超过原有数据内存的 2 倍大小。另外一个 Redis 实例里冷数据占的比例往往是比较高的，所以很少会出现所有的页面都会被分离，被分离的往往只有其中一部分页面。每个页面的大小只有 4K，一个 Redis 实例里面一般都会有成千上万的页面。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

这里之需要需要通知父线程，是因为父线程要做个记录，保留最后一次持久化的时间。

2、RDB配置

（1）指定备份文件的名称

在redis.conf中，可以修改rdb备份文件的名称，默认为dump.rdb，如下：

（2）指定备份文件存放的目录

在redis.conf中，rdb文件的保存的目录是可以修改的，默认为Redis启动命令所在的目录，如下

（3）触发RDB备份

方式1：自动备份，需配置备份规则

可在redis.conf中配置自动备份的规则，默认规则如下：

save用来配置备份的规则

save的格式： save 秒钟写操作次数

默认是1分钟内修改了1万次，或5分钟内需修改了10次，或30分钟内修改了1次。

示例：设置20秒内有最少有3次key发生变化，则进行备份

save 20 3

方式2：手动执行命令备份（save | bgsave）

有2个命令可以触发备份。

save：save时只管保存，其他不管，全部阻塞，手动保存，不建议使用。
bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端情况。

可以通过 lastsave 命令获取最后一次成功生成快照的时间（获取到的是时间戳）。

方式3：flushall命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

（4）动态停止RDB： redis-cli config set save "" #save后给空值，表示禁用保存策略。

3、redis.conf 其他一些配置

（1）stop-writes-on-bgsave-error：当磁盘满时，是否关闭redis的写操作

stop-writes-on-bgsave-error用来指定当redis无法写入磁盘的话，是否直接关掉redis的写操作，
推荐yes。

（2）rdbcompression：rdb备份是否开启压缩

对于存储到磁盘中的rdb快照文件，可以设置是否进行压缩，如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，推荐yes。

（3）rdbchecksum：是否检查rdb备份文件的完整性

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

4、RDB的备份恢复

（1）先通过CONFIG GET dir查询rdb文件的目录，这其实就是查的redis.conf文件当中通过dir设置的目录

（2）停止Redis
（3）拷贝迁移的redis备份文件（dump.rdb）到CONFIG GET dir查询出来的指定目录下。

cp dump.rdb dump.rdb

（4）重新启动redis服务

5、RDB优缺点

优势：

适合大规模数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
基于二进制存储的，恢复速度快

劣势：

Fork的时候，内存中的数据会被克隆一份，大致2倍的膨胀，需要考虑
虽然Redis在fork的时候使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down的话，就会丢失最后一次快照后所有修改

三、AOF（Append Of File）

1、AOF原理

AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。

假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

（1）写入机制

Redis 在收到客户端修改命令后，先进行相应的校验，如果没问题，就立即将该命令存追加到 .aof 文件中，也就是先存到磁盘中，然后服务器再执行命令。这样就算遇到了突发的宕机情况情况，也只需将存储到 .aof 文件中的命令，进行一次“命令重演”就可以恢复到宕机前的状态。

（2）写入缓存

在上述执行过程中，有一个很重要的环节就是命令的写入，这是一个 IO 操作。Redis 为了提升写入效率，它不会将内容直接写入到磁盘中，而是将其放到一个内存缓存区（buffer）中，等到缓存区被填满时采用异步真正将缓存区中的内容写入到磁盘里。

这就意味着如果机器突然宕机，AOF 日志内容可能还没有来得及完全刷到磁盘中，这个时候就会出现日志丢失。那该怎么办？

Redis 为数据的安全性考虑，同样为 AOF 持久化提供了策略配置，打开 Redis 配置文件，如下图所示：

上述配置策略说明如下：

Always：服务器每写入一个命令，就调用一次 fsync函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢；
Everysec（默认）：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；
No：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全。

注意：Linux 系统的 fsync() 函数可以将指定文件的内容从内核缓存刷到硬盘中。

由于是 fsync 是磁盘 IO 操作，所以它很慢！如果 Redis 执行一条指令就要 fsync 一次（Always），那么 Redis 高性能将严重受到影响。

在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作（ Everysec），这样既保持了高性能，也让数据尽可能的少丢失。最后一种策略（No），让操作系统来决定何时将数据同步到磁盘，这种策略存在许多不确定性，所以不建议使用。

（3）重写机制

Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，“重演”整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。

为了让 aof 文件的大小控制在合理的范围内，Redis 提供了 AOF 重写机制，手动执行BGREWRITEAOF命令，开始重写 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

通过 bgrewriteaof 操作后，服务器会生成一个新的 aof 文件，该文件具有以下特点：

新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令。
即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改

重写机制AOF文件对比：

（4）自动触发AOF重写

Redis 为自动触发 AOF 重写功能，提供了相应的配置策略。如下所示：修改 Redis 配置文件，让服务器自动执行 BGREWRITEAOF 命令。

#默认配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。

该配置项表示：触发重写所需要的 aof 文件体积百分比，只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。

（5）整个下来运行流程如下：

客户端的请求写命令会被append追加到AOF缓冲区内
AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

2、AOF配置

AOF默认不开启，可以在 redis.conf 文件中对AOF进行配置开启：

appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
appendfilename "appendonly.aof" # aof文件名称，默认为appendonly.aof
dir ./ # aof文件所在目录，默认./，表示执行启动命令时所在的目录

3、AOF的备份恢复

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复

修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）
恢复：重启redis然后重新加载

异常恢复

修改默认的appendonly no，改为yes
如遇到aof文件损坏，通过 redis-check-aof --fix appendonly.aof 进行恢复，appendonly.aof是文件名

4、重写流程

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

no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进行AOF重写的时候，如果此时有写操作进来，此时写操作的命令会放在aof_buf缓存中（内存中），而不会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。

默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保证了数据的安全性。但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）
如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

但在数据量很大的场景，因为两者都会消耗磁盘IO，对磁盘的影响较大，可以将其设置为“yes”减轻磁盘压力，但在极端情况下可能丢失整个AOF重写期间的数据。

5、AOF优缺点

优势：

备份机制更稳健，丢失数据概率更低
可读的日志文本，通过操作AOF文件，可以处理误操作

劣势：

比RDB占用更多的磁盘空间
恢复备份速度要慢
每次读写都同步的话，有一定的性能压力
存在个别bug，造成不能恢复

总结：

AOF文件是一个只进行追加的日志文件
Redis可以在AOF文件体积变得过大时，自动地在后台对AOF文件进行重写
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
根据所使用的fsync策略，AOF的速度可能会慢于RDB

四、AOF和RDB对比

官方推荐2个都启用。
如果对数据不敏感，可以单独用RDB。
不建议单独使用AOF，因为可能会出现BUG。
如果只是做纯内存缓存，可以都不用。

五、AOF和RDB官网建议

RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，AOF命令以redis协议追加保存每次写的操作到AOF文件末尾
Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式
同时开启两种持久化方式：在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要是只用AOF呢？
建议不要，因为RDB更适合用于备份数据库，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段
性能建议
- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这一条
- 如果使用AOF，好处是在最恶劣的情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了
- AOF的代价，一是带来持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据（aof_rewrite_buf）写到文件造成的阻塞几乎是不可避免的
- 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基数大小默认值64M（autoaof-rewrite-min-size）太小了，可以设置到5G以上
- 默认超过原大小100%（auto-aof-rewrite-percentage）大小时重写可以改到适当的数值。

通常 Redis 的主节点是不会进行持久化操作，持久化操作主要在从节点进行。从节点是备份节点，没有来自客户端请求的压力，它的操作系统资源往往比较充沛。

但是如果出现网络分区，从节点长期连不上主节点，就会出现数据不一致的问题，特别是在网络分区出现的情况下又不小心主节点宕机了，那么数据就会丢失，所以在生产环境要做好实时监控工作，保证网络畅通或者能快速修复。另外还应该再增加一个从节点以降低网络分区的概率，只要有一个从节点数据同步正常，数据也就不会轻易丢失。

在这里插入图片描述