【Redis7学习日记】—— Redis持久化

• Redis 的持久化是它的一大特性，可以将内存中的数据写入到硬盘中
  • 主要分为 RDB 和 AOF 两种，接下来我们将展开叙述
    • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
    • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据

一、RDB

• RDB持久性以 指定的时间间隔，执行数据集时间点快照
  • 在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时将硬盘快照文件读回到内存里
  • 保存备份时执行的是全量快照 【所有数据】
  • RDB 保存的是 dump.rdb 文件
    

🌔 1、配置文件的版本区别

（1）Redis 6.0.16 以下

（2）Redis6.2 以及 Redis 7.0.0

• 那么我们如何使用 RDB 呢？

1.1 自动触发

🌔 1、进行配置

• 我们可以通过设置配置文件自动触发 RDB 的功能

• 首先，我们通过 vim /myredis/redisconfig7.conf 编辑我们拷贝的 redis 配置文件

• 对于 Redis7 中配置RDB触发机制的代码是这样的 save <seconds> <changes>

  • 此处就设置为 5s内有2次写操作就触发 save 5 2
    

• 之后我们需要修改 rdb 文件的保存位置，通过 dir /myredis/dumpfiles 指令完成
  

• 之后在配置文件中修改我们 rdb 文件的名字 dbfilename dump6379.rdb
  > 那么我们如何触发备份呢？

• 第一种情况就是达到我们设置的要求，五秒内写入两条
  

• 第二种情况：
  

🌔 2、如何恢复呢？

• 在我们重启 Redis 服务器登录客户端之后，就会去寻找我们的RDB备份文件
• 但是，我们需要知道我们通过 flushdb 清空模拟异常时
  • 执行flushdb、flushall命令也会产生 dump.rdb 文件，这样重启后数据集还是空的，所以没有任何意义
  • 所以我们需要在模拟前将之前的 rdb 文件改名【防止被覆盖为空，导致测试失败】
  • 然后执行完 flushdb 命令后，将有数据的rdb文件改回原名，这样重启Redis就会自动加载这个文件
    
• 我们要注意：物理恢复一定要把服务和备份分机隔离
  • 不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了
    

1.2 手动触发

• Redis 提供了save、basave 两个命令来生成 RDB 文件
• 那么这两种方式有什么区别呢？

🌔 1、save

• 对于 save 命令，在主程序中执行会阻塞当前 redis 服务器，直到持久化工作完成
  • 就是在执行 save 命令期间，Redis 不能处理其他命令 【线上禁止使用】
    
    

🌔 2、bgsave

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

那么 fork 是什么呢？

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。

• 我们通过 lastsave 命令可以获取最后一次成功执行快照的时间
  

---

1.3 优缺点

🌔 优势

• 适合大规模的数据恢复
• 按照业务定时备份
• 对数据完整性和一致性要求不高
• RDB 文件在内存中的加载速度要比 AOF 快得多

🌔 劣势

• 在一定间隔时间做一次备份，可能造成快照之间的数据丢失
• 内存数据的全量同步，如果数据量太大会导致 I/O 严重影响服务器性能
• RDB 依赖于主进程的 fork，数据集很大的情况下可能导致服务请求的瞬间延迟
• fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

模拟数据丢失：

• 正常录入数据：
  
• 使用 kill 命令杀死进程
  
• 重启服务器查看结果
  

1.4 其他配置信息

🌔 1、如果我们生成的 dump.rdb 文件出现了问题怎么办？

• Redis 为我们提供了 redis-check-rdb 文件名 指令可以修复我们的 RDB 文件
  

🌔 2、哪些情况下会触发 RDB 快照？ 【全局快照写入硬盘】

• 当前操作满足了我们在配置文件中默认的快照配置
• 手动执行了 save 或 bgsave 命令
• 执行了 flushdb 或 flushall 命令 【产生的 dump.rdb 文件里面是空的】
• 主从复制时，主节点自动触发

🌔 3、如果我们不想使用 RDB 的快照功能怎么办？

• 方式一：在命令行通过 redis-cli config set save "" 指令禁用
• 方式二：通过修改配置文件禁用

🌔 4、RBD优化配置项详解？ 【在配置文件中 snapshotting 相关模块】

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

1.5 总结

二、AOF

• 是Redis提供的另一种持久化机制
• 以日志的形式记录每个写操作，将Redis执行过的所有写指令记录下来，只许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据
  • Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
• 默认情况下，Redis 是没有开启 AOF 的，需要在Redis的核心配置文件中进行配置
• 生成的是 appendonly.aof 文件
  

2.1 持久化流程

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

2.2 缓冲区写回策略

• Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘
• no：操作系统控制写回，只是把日志写道 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
• everysec：每秒写回，每个写命令执行完，只是先把日志写道 AOF 文件的缓冲区，每隔1s把缓冲区中的内容写入磁盘

2.3 配置与使用

🌔 配置文件说明

• 如何开启 AOF？

  • 只需修改我们的配置文件，将 appendonly 属性设置为 yes
    

• 使用默认回写策略，即 appendfsync everysec 数据先至于 AOF 缓冲区，每隔1s写入磁盘

• AOF 文件保存路径：

  • 在 Redis6 中，与 RDB配置的路径一致，都是通过 dir 字段设置
  • 在 Redis7 中， 会在我们 dir 指定的路径后添加一个 appenddirname 属性值的目录
    

• AOF文件保存名称：

  • 在 Redis6 中，使用配置文件中的 appendfilename 指定文件名

  • 在 Redis7 中，使用了 Multi Part AOF 的设计

    • base 基本文件 【在我们增量文件达到一定程度，就会重写到基本文件中】
    • incr 增量文件 【实际记录我们每次写操作的文件（增、删、改）】
    • manifest 清单文件

  
  

🌔 正常恢复

• 启动：修改默认的 appendonly no 为 yes 【开启AOF功能】
• 写操作继续，生成 AOF 文件到我们指定的目录中
  • 恢复1：重启 Redis 然后重新加载并执行我们 AOF 文件中的写操作
  • 恢复2：【是因为我们通过 flushdb + shutdown 的方式退出（重新执行aof后还是为空）】

    • 写入数据进 Redis，然后执行 flushdb + shutdown 命令

    • 生成了 dump.rdb 和 appenddirname.aof 文件

    • 备份新生成的 aof.bak，然后删除 dump/aof,尝试恢复
      

    • 重启 Redis 查看结果
      

    • 停止服务器，然后将我们有数据的 aof 文件改回原名，再次重启 Redis 查看结果
      
      

🌔 异常恢复

• 就是我们生成的 AOF 文件存在问题，我们改如何恢复我们的数据？
  • 此处通过修改 AOF 文件模拟错误指令vim /myredis/appendonlydir/appendonly.aof.1.incr.aof
    
• 保存后我们尝试重启 Redis，发现无法连接到客户端
  
• 我们可以采用 Redis 为我们提供的 AOF 文件修复命令 【重点：不要忘记 --fix 选项】
  
• 再次重启 Redis 并连接客户端，发现数据恢复成功
  

2.4 优缺点

📖 优势

• 可以更好的保护数据不丢失、性能高、可做紧急恢复

📖 劣势

• 针对相同大小的数据集，AOF文件的体积要大于RDB文件，恢复速度也更慢一些
• AOF 运行效率慢于 RDB，每秒同步策略较好，不同步效率和RDB一样

2.5 重写机制

• 为什么会产生重写机制？

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

• 什么是重写机制？

  • 启动 AOF 文件的内容压缩，只保留恢复数据的最小指令集

• 官网给出的相关默认配置：【同时满足设定的多个规则才会重写】

  • 我们当前 AOF 文件是上一个 AOF 文件大小的一倍
  • 我们当前的 AOF 文件大小已经达到了 64MB
    

• 当然，我们也可以使用 bgrewriteaof 命令手动触发重写功能

接下来我们通过一个案例来演示：

1️⃣ 需求：

2️⃣ 准备工作：

• 删除之前的 aof、rdb 文件，清除干扰项

• 开启 AOF 功能 【配置文件 appendonly yes】

• 关闭 AOF 和 RDB 的混合功能，因为此处我们就是要演示 AOF 重写功能
  

• 修改重写峰值【因为只是为了要是效果，文件内容没必要达到64MB】
  

3️⃣ 两种方式触发重写：

（1）自动触发案例

• 在上述配置完成后，重启 Redis 服务器，使用 set 指令查看是否可以正常生成我们的三个 AOF 文件
  

• 查看我们的三大文件
  

• 不断覆盖我们 k1 键对应的 value，使我们的 appendonly.aof.1.incr.aof 文件大小达到触发重写大小
  

• 触发重写后我们重新查看增量文件内容 >> 只保存了 k1 最后对应的 value
  
  （2）手动触发案例

• 在客户端向服务器发送 barewriteaof 命令

• 通过我们增量文件大小的改变，我们知道重写功能成功触发了
  

4️⃣ 案例总结

重写原理总结：

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

配置文件项说明：

三、混合持久化

• 就是开启 AOF 和 RDB 混合功能实现持久化
  • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
  • AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾.
    
• 那么我们开启两种功能，数据恢复和加载流程是怎样的呢？
  • 实际重启的时候只会加载 AOF 文件，不会加载 RDB 文件
    • 因为 AOF 文件可以保证数据更完整
    • 而 RDB 文件更适合用于做备份
      

❤️ 总结：

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

• 如何开启混合功能呢？

  • 在配置文件中，做如下设置 `aof-use-rdb-preamble yes

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

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

四、纯缓存模式

• 什么是纯缓存模式呢？

  • 就是关闭 RDB 和 AOF 的功能，Redis 只用来做缓存，无需实现持久化

• 那么我们如何关闭 RDB 和 AOF 功能呢？

  • 都可以在配置文件中设置
    • save "" 就可以关闭 RDB 的功能
    • appendonly no 就可以关闭 AOF 的功能

• 尽管我们关闭了持久化的功能（通过配置文件的方式），但是我们还可以生成RDB、AOF文件：

  • 我们可以通过 save、bgsave 指令生成 RDB 文件
  • 我们可以通过 bgrewriteaof 指令生成 AOF 文件