Redis7--基础篇3（持久化）

持久化介绍

官网地址：
https://redis.io/docs/manual/persistence

• RDB(Redis DataBase)
• AOF(Append Only File)
• RDB + AOF
  

---

RDB模式(Redis DataBase)

RDB 持久性以指定的时间间隔执行数据集的时间点快照。
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是
快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。

在指定的时间间隔内将内存中的数据集快照写入磁盘也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。

redis.conf配置文件

• 6.0.16版本以下
  
  

• 6.2以及7.0版本
  

开启备份

1.修改配置文件

5秒或2次

2. 定义dump文件保存路径

3. 定义dump文件名称

测试

恢复备份

1. 将备份文件移动到redis安装目录并启动服务

flushall、flushdb命令也会产生备份文件
物理恢复，服务、备份需要分机隔离，防止硬盘损坏后备份文件也丢失。

手动触发备份

redis提供了两个命令来生成RDB文件， save 和 bgsave 。

save

会阻塞当前redis服务器，知道持久化工作完成，在执行save命令期间，redis不能处理其他命令，生产禁止使用。

bgsave

redis会在后台异步进行快照操作，不阻塞，在进行快照同时还能响应客户端请求，该触发方式会fork一个子进程，由子进程复制持久化过程。
Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

劣势

在备份间隔期间redis意外down调的话，会丢失当前至最新一次快照的数据。
内存数据全量同步，如果数据量太大会造成占用大量I/O，影响服务器性能。
RDB依赖于主进程的fork，在更大的数据集中，这可能导致服务的请求的瞬间延迟，fork的时候内存中的数据被克隆了一份，需要考虑容量。

如何检修dump.rdb文件

触发RDB快照的情况

• 配置文件中默认的快照配置
• 执行save、bgsave命令
• 执行flushdb、flushall命令，但是生成的dump.rdb文件是空的，没有意义。
• 属性shutdown并且没有设置开启AOF持久化
• 主从复制，主节点自动触发

禁用快照

• 启动服务时输入相关参数

  redis -cli config set save ""
  1

• 修改配置文件
  

RDB模式相关配置参数详解

• save 快照的频率

• dbfilename 快照文件的名称

• dir 快照文件的目录

• stop-writes-on-bgsave-error
  默认yes
  如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，
  也能确保redis继续接受新的写请求
  

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

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

• rdb-del-sync-files
  
  在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

小总结

---

AOF模式(Append Only File)

介绍

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认情况下，redis是没有开启AOF的，如果开启的话需要修改配置文件。

配置AOF开启、AOF备份文件路径、AOF备份文件名

AOF持久化工作流程

1-Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2-在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3-AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4-随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5-当Redis Server 服务器重启的时候会从AOF文件载入数据。

AOF缓冲区三种写回策略

• always
  同步写回，每个写命令执行完立刻同步的将日志写回磁盘
• everysec
  每秒写回，每个写命令执行完，只是先把日志写到AOF文件内存缓冲区，每隔一秒把缓冲区的内容写入磁盘
• no
  操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件

AOF文件路径

redis6

AOF文件与RDB文件的位置一样，在此配置

redis7

最终保存路径为 dir+appenddirname

AOF文件名称

redis6

有且只有一个

redis7

恢复

正常恢复

• 配置文件中 appendonly no 改为 appendonly yes
• 重启服务

异常恢复

• 重启服务会进入AOF文件的载入，如果AOF文件有问题，则无法启动
• 异常修复命令：redis -check -aof --fix

优势

可紧急恢复、性能高、数据更不易丢失

劣势

对于相同的数据集来说，AOF文件要远大于RDB文件，恢复速度慢于RDB
AOF运行效率要慢于RDB，每秒同步策略较好

AOF重写机制

介绍

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，或者可以手动使用命令 bgrewriteaof 来重新。

触发机制

注意 ，同时满足，且的关系才会触发。
1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小
3 满足配置文件中的配置项后，Redis会记录上次重写的AOF文件大小，默认配置是当AOF文件大小是上次write后大小的一倍且文件大于64MB时
4 可以执行bgrewriteof命令

总结

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

原理

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

配置项详细说明

小总结

---

RDB-AOF混合持久化模式

在同时开启RDB和AOF持久化时，重启只会加载AOF文件，不会加载RDB文件。

RDB+AOF混合方式
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据

开启混合方式设置

设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

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

---

纯缓存模式

同时关闭RDB模式和AOF模式，但仍可以使用save、bgsave命令来生成rdb文件，用bgrewriteaof命令来生成aof文件。