Redis 之RDB、AOF、混合持久化

文章目录

  • Redis 的持久化机制有哪几种
  • 持久化之RDB
    • 触发机制
    • RDB持久化流程
    • RDB文件压缩
    • RDB的优缺点
  • 持久化之AOF
  • RDB和AOF区别
  • Redis重启时加载持久化文件
  • 混合持久化的实现原理、优缺点
  • RDB、AOF、混合持久,应该用哪一个

Redis高可用详解:持久化技术及方案选择
redis4.0深入持久化
面试必问的 Redis:RDB、AOF、混合持久化

Redis 的持久化机制有哪几种

RDB、AOF、混合持久化(Redis4.0引入)

持久化之RDB

原理: RDB持久化是将 Redis 在内存中的数据库状态(数据库的键值对等信息)生成快照保存到磁盘里面,生成的 RDB 文件是经过压缩的二进制文件。

触发机制

触发命令: savebgsave(background save)

  • save:阻塞当前Redis服务器,直到RDB过程完成为止,对于内存 比较大的实例会造成长时间阻塞,线上环境不建议使用。
  • bgsave:Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。

Redis内部所有的涉 及RDB的操作都采用bgsave的方式,而save命令已经废弃。

自动触发RDB的持久化 机制:
save m n 表示m秒内数据集存在n次修改时,自动触发bgsave
从节点执行全量复制操作时,主节点自动执行bgsave生成RDB文件并发送给从节点。
默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave

save 900 1 # 900秒内有1个key发生了变化,则触发保存RDB文件
save 300 10 # 300秒内有10个key发生了变化,则触发保存RDB文件
save 60 10000 # 60秒内有10000个key发生了变化,则触发保存RDB文件

Redis 之RDB、AOF、混合持久化_第1张图片

RDB持久化流程

Redis 之RDB、AOF、混合持久化_第2张图片

RDB文件压缩

Redis默认采用LZF算法对生成的RDB文件做压缩处理,压缩后的文件远远小于内存大小,默认开启,可以通过参数config set rdbcompression{yes|no}动态修改。
虽然压缩RDB会消耗CPU,但可大幅降低文件的体积,方便保存到硬盘或通过网络发送给从节点,因此线上建议开启。

RDB的优缺点

优点:

  • RDB是一个紧凑压缩的二进制文件。非常适用于备份,用于灾难恢复。
  • Redis加载RDB恢复数据远远快于AOF的方式。因为AOF文件中存放的是操作命令。

缺点:

  • 一旦Redis异常退出,就会丢失最后一次快照以后更改的数据,这样就会造成数据不完整性或者不一致。
  • 不能做到实时持久化,每次都会创建子线程,进行备份数据时,会生成临时文件,属于重量级操作,频繁执行成本过高。
  • RDB二进制文件可能出现新老版本不兼容问题。

持久化之AOF

原理: AOF持久化策略是将发送到Redis服务端的每一条目录都记录下来,并保存到硬盘中的AOF文件。

配置方式:(默认不开启)
在这里插入图片描述
AOF 持久化功能的实现可以分为三个步骤: 命令追加、文件写入、文件同步。

命令追加: 当 AOF 持久化功能打开时,服务器在执行完一个写命令之后,会将被执行的写命令追加到服务器状态的 aof 缓冲区(aof_buf)的末尾。

文件写入与文件同步: 为什么将 aof_buf 的内容写到磁盘上需要两步操作,这边简单解释一下。
Linux 操作系统中为了提升性能,使用了页缓存(page cache)。当我们将 aof_buf 的内容写到磁盘上时,此时数据并没有真正的落盘,而是在 page cache 中,为了将 page cache 中的数据真正落盘,需要执行 fsync / fdatasync 命令来强制刷盘。这边的文件同步做的就是刷盘操作,或者叫文件刷盘可能更容易理解一些。

aof 缓冲区的内容先写入到 Linux 的页缓存,然后通过 fsync 命令强制同步到磁盘。

AOF文件重写策略:
重写是优化AOF文件,可以使用BGREWRITEAOF命令来重写AOF文件。
AOF持久化会保存每一条被执行的写命令,那么随着服务器运行时间的增长,对应的AOF文件内容会越来越多,文件也会越来越大,从而对服务器造成影响,为此,Redis提供了文件重写的功能,来解决AOF文件过大问题,它是通过重写程序aof_write实现的。
AOF文件中重写后全部都是Redis主进程中全部数据的写命令。

为什么要重写呢?

  • 因为同一个key可能会设置两次value值,这时在AOF中有两条记录,重写后只会保存后面的记录,节省数据恢复的时间。
  • 进程内已经超时的数据不再写入文件。
  • 多条写命令可以合并为一个,如:lpush list a、lpush list b、lpush list c可以转化为:lpush list a b c
  • 如果你对一个计数器调用了 100 次 INCR , 那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录。重写后使用一条 SET 命令已经足以保存计数器的当前值了。

Redis 之RDB、AOF、混合持久化_第3张图片
重写后的AOF文件为什么可以变小?

  • 进程内已经超时的数据不再写入文件。
  • 新的AOF文件只保留最终数据的写入命令。

AOF重写降低了文件占用空间,除此之外,另一个目的是:更小的AOF文件可以更快地被Redis加载。

为什么要设计两种持久化方式
因为RDB方式存在的缺陷,如果在没有触发快照的情况下,机器宕机,数据会丢失。
AOF 在过去曾经发生过这样的 bug : 因为个别命令的原因,导致 AOF 文件在重新载入时,无法将数据集恢复成保存时的原样。

总结: 作为缓存可以不用持久化,大不了走DB,作为内存数据库一定要持久化了。

RDB和AOF区别

RDB是全量的,AOF是实时的。
RDB适合备份,默认开启。
AOF默认不开启,如果AOF开启,Redis启动时会从AOF文件恢复数据,否则从RDB文件恢复数据。

Redis重启时加载持久化文件

在Redis的实际使用过程中,可以将RDB持久化和AOF持久化同时使用,RDB用于灾难数据恢复(快速的数据恢复),AOF用于服务器重启数据恢复(AOF保证据不丢失)。

Redis重启时加载持久化文件的顺序: 如果同时启用了 AOF 和 RDB,Redis 重新启动时,会使用 AOF 文件来重建数据集,因为通常来说, AOF 的数据会更完整。
Redis 之RDB、AOF、混合持久化_第4张图片

流程说明:

  • 1、AOF持久化开启且存在AOF文件时,优先加载AOF文件;打印日志:DB loaded from append only file: 5.841 seconds
  • 2、AOF关闭或者AOF文件不存在时,加载RDB文件;打印日志:DB loaded from disk: 5.586 seconds
  • 加载AOF/RDB文件成功后,Redis启动成功。
  • 3、AOF/RDB文件存在错误时,Redis启动失败并打印错误信息。

混合持久化的实现原理、优缺点

描述: 混合持久化并不是一种全新的持久化方式,而是对已有方式的优化。混合持久化只发生于 AOF 重写过程。使用了混合持久化,重写后的新 AOF 文件前半段是 RDB 格式的全量数据,后半段是 AOF 格式的增量数据。

整体格式为: [RDB file][AOF tail]

开启: 混合持久化的配置参数为 aof-use-rdb-preamble,配置为 yes 时开启混合持久化,在 Redis4 刚引入时,默认是关闭混合持久化的,但是在 Redis5 中默认已经打开了。

关闭: 使用 aof-use-rdb-preamble no 配置即可关闭混合持久化。

混合持久化本质是通过 AOF 后台重写(bgrewriteaof 命令)完成的,不同的是当开启混合持久化时,fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件,然后再将 AOF 重写缓冲区(aof_rewrite_buf_blocks)的增量命令以 AOF 方式写入到文件,写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

优点: 结合 RDB 和 AOF 的优点, 更快的重写和恢复。
缺点: AOF 文件里面的 RDB 部分不再是 AOF 格式,可读性差。

RDB、AOF、混合持久,应该用哪一个

如果想尽量保证数据安全性, 你应该同时使用 RDB 和 AOF 持久化功能,同时可以开启混合持久化。

如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。

如果你的数据是可以丢失的,则可以关闭持久化功能,在这种情况下,Redis 的性能是最高的。

你可能感兴趣的:(Redis)