【redis持久化模式】两种持久化方式、概念、原理、如何使用、优劣势_Redis05

1、RDB

1）RDB概念：

• 在指定的时间间隔内，将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
• rdb 保存的是dump.rdb文件。
• 相关配置在配置文件的位置 - 在redis.conf搜寻### SNAPSHOTTING ###。

save 60 1000
save 300 100
1
2

• 分析：每隔60s，如果超过1000个key发生了变更，就生成一个新的dump.rdb文件，当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照。

2）RDB流程：

• RDB在保存RDB文件时父进程只需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。

• 注意：Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

3）如何触发RDB快照？

• 手动触发：执行bgsave命令后，异步执行快照操作（通过lastsave命令获取最后一次成功执行快照的时间）
• 自动触发：配置 redis.conf 文件中 SNAPSHOTTING（snapshotting） 属性。例如：
  • save 900 1 900秒有一条数据改变就保存。
  • save 300 10 300秒有10条数据改变就保存。
  • save 60 10000 600秒有10000条数据改变就保。

4）如何恢复快照中的数据？

• 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。
  • 注意：Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。
  • 获取 redis 的安装目录：可以使用 config get dir 命令

5）如何禁用RDB持久化？

• 1）在redis.conf配置文件中：注释掉所有的 save 行来停用RDB功能或者直接一个空字符串来实现停用：save “”
• 2）命令：通过命令config set save “” 停用RDB功能。

6）RDB的优劣势：

• 1.劣势
  • 1）RDB是在一定间隔时间做一次备份，所以如果Redis服务意外停止的话就会丢失最后一次快照的所有修改。
  • 2）数据丢失的风险大，对数据完整性和一致性要求不高。
  • 3）RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作（内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑），当数据集比较大的时候，fork的过程是非常耗时的，频繁执行成本过高(影响性能)，可能会导致Redis在一些毫秒级不能响应客户端请求。
  • 4）RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
• 2.优势
  • 1）RDB是一个非常紧凑(compact)的文件，它保存了Redis在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
  • 2）RDB在恢复大数据集时的速度比 AOF 的恢复速度要快。
  • 3）生成RDB文件的时候，Redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作，所以RDB持久化方式可以最大化Redis性能。

7）小结：

• RDB是一个非常紧凑的文件。
• RDB在保存RDB文件时父进程只需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。
• 数据丢失风险大。
• RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候fork的过程是非常耗时的，可能会导致Redis在一些毫秒级不能回应客户端请求。

2、AOF

1）AOF概念：

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

• aof保存的是appendonly.aof文件。

2）AOF启动/修复/恢复：

• 开启：

  • 1）将redis.conf 文件中 APPEND ONLY MODE 下appendonly属性修改为yes开启 AOF 持久化方式。

• 正常恢复

  • 1）将有数据的appendonly.aof文件复制一份保存到 redis 安装目录(config get dir)
  • 2）恢复：重启redis然后重新加载

• 异常恢复

  • 1）备份被写坏的AOF文件（先保存一份）
  • 2）修复：
    • 使用redis-check-aof --fix appendonly.aof对AOF文件进行修复（如果AOF文件没有异常可以忽略此步骤）
  • 3）恢复：重启redis然后重新加载

3）AOF重写你知道吗？

• （1）概念：
  • AOF持久化是采用文件追加的方式，Redis不断将写命令记录到 AOF 文件中，随着数据越来越多，AOF文件也会随之越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
  • 为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 。

• （2）重写原理：

  • AOF文件持续增长而过大时，需要重写AOF文件时，Redis会fork出一条新进程来将文件重写（也是先将数据写到临时文件中然后再替换原来的AOF文件），遍历新进程内存中的数据，然后用一条命令去代替之前的多条命令，生成一个新的文件后去替代原来的AOF文件。
  • 注意：
    • 1.子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。
    • 2.子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

• （3）AOF 重写缓冲区：

  • 重写缓冲区解决的问题：
    • 因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，可能导致当前数据库状态和重写后的 AOF 文件状态不一致。
  • 解决方案：
    • 为了解决数据不一致的问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。
    • 当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。
    • 这样可以保证 AOF 重写对服务器造成的影响降到了最低。

• （4）重写触发时机：

  • 通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100（100%，一倍），以及auto-aof-rewrite-min-size：64mb 配置。
  • 也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

4）AOF优劣势

• 1.劣势：

  • 1）相同数据集的数据而言，AOF 文件通常会比 RDF 文件体积更大，且恢复速度慢于RDB。
  • 2）虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
  • 3）RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

• 2.优势：

  • 1）AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
  • 2）AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只向 AOF 文件写入的命令是残缺片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
  • 3）AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

5）小结

• AOF文件时一个只进行追加的日志文件

• Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写

• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松

• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积

• 根据所使用的fsync 策略，AOF的速度可能会慢于RDB

• redis4.0使用混合持久化：其中aof就不需要全量了，只需要在rdb之后进行增量。redis重启先加载rdb然后再加载增量的aof日志。