2.Redis之持久化

2.1 RDB

2.1.1 概述

• RDB（Redis Database）：RDB 持久化以指定得时间间隔执行数据集得时间点快照。

• 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。

• 恢复时再将硬盘快照文件直接读回到内存中。

• 这个快照文件就称为 RDB 文件（dump.rdb），其中，RDB 就是 Redis DataBase 的缩写。

2.1.2 触发

自动触发：

• redis.conf 里配置的 save<seconds><changes>

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

• 物理恢复，一定服务和备份分机隔离

手动触发：

• Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave

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

  • bgsave（默认）：Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会 fork 一个子进程由子进程复制持久化过程

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

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

情况触发：

• 配置文件中默认的快照配置

• 手动 save/bgsave 命令

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

• 执行 shutdown 且没有设置开启 AOF 持久化

• 主从复制时，主节点自动触发

2.1.3 优势

官网：

总结

1. 适合大规模的数据恢复

2. 按照业务定时备份

3. 对数据完整性和一致性要求不高

4. RDB 文件在内存中的加载速度要比 AOF 快得多

2.1.4 劣势

官网

总结

1. 在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失

2. 内存数据的全量同步，如果数据量太大会导致 I/0 严重影响服务器性能

3. RDB 依赖于主进程的 fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。

4. fork 的时候内存中的数据被克隆了一份，大致 2 倍的膨胀性，需要考虑

2.2 AOF

2.2.1 概述

• 以日志的形式来记录每个写操作，将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

• 默认情况下，redis 是没有开启 AOF（append only file）的。开启 AOF 功能需要设置配置：appendonly yes。

2.2.2 工作流程

1. Client 作为命令的来源，会有多个源头以及源源不断的请求命令。

2. 在这些命令到达 RedisServer 以后并不是直接写入 AOF 文件，会将其这些命令先放入 AOF 缓存中进行保存。这里的 AOF 缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘 I0 操作。

3. AOF 缓冲会根据 AOF 缓冲区同步文件的三种写回策略将命令写入磁盘上的 AOF 文件。

   1. always：同步写回，每个命令执行完立刻同步地将日志协会磁盘

   2. everysec（默认）：每秒写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔 1s 把缓冲区的内容写入磁盘

   3. no：操作系统控制的写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

   

4. 随着写入 AOF 内容的增加为避免文件膨胀，会根据规则进行命令的合并（又称 AOF 重写），从而起到 AOF 文件压缩的目的。

5. 当 RedisServer 服务器重启的时候会从 AOF 文件载入数据。

2.2.3 优劣

优势

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

劣势

2.2.4 重写机制

一句话：启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集

触发机制

• 自动触发（默认配置）

  

  1. 根据上次重写后的 aof 大小，判断当前 aof 大小是不是增长了 1 倍

  2. 重写时满足的文件大小

  3. 注意 ，同时满足，且的关系才会触发

• 手动触发

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

重写原理

1. 在重写开始前，redis 会创建一个“重写子进程”，这个子进程会直接读取内存中的数据库状态，并将其包含的指令进行分析压缩并写入到一个临时文件中

2. 于此同时，主进程会将新接受到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。

3. “重写子进程"完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中

4. 追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中

5. 重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似

2.2.5 AOF 优化配置

2.2.6 总结

2.3 RDB + AOF

2.3.1 官网建议

2.3.2 如何共存

2.3.3 数据恢复顺序和加载流程

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

• RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢？

  • 作者建议不要，因为 RDB 更适合用于备份数据库（AOF 在不断变化不好备份），留着 rdb 作为一个万一的手段。

2.3.4 开启混合模式

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

• RDB+AOF 的混合方式---------> 结论：RDB 镜像做全量持久化，AOF 做增量持久化

先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的 RDB 记录。这样的话，重启服务的时候会从 RDB 和 AOF 两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。

简单来说：混合持久化方式产生的文件一部分是 RDB 格式，一部分是 AOF 格式。----》AOF 包括了 RDB 头部+AOF 混写