写点什么

你了解 Redis RDB 快照吗

  • 2022-10-18
    广东
  • 本文字数:1104 字

    阅读完需:约 1 分钟

前言

我们都知道,Redis 有两大持久化机制:AOF 日志和 RDB 快照。AOF 方法每次执行只记录命令,持久化的数据量不大。但是在 AOF 日志恢复时,需要把日志的每条命令都执行一遍。如果日志很多,恢复过程就会变得很漫长。因此,Redis 提供了另一种持久化机制,那就是 RDB 快照。

RDB 快照写入规则

和 AOF 记录命令不同,RDB 记录的当前的数据。Redis 有提供 2 个命令来生成 RDB 快照文件,分别是 save 和 bgsave。

  • save: 这种方式在主线程执行,容易导致阻塞;

  • bgsave: 创建一个子进程来执行 RDB 写入工作。这种方式可避免主线程的阻塞(默认配置)

这里你可能有疑问,快照过程中,如果有数据做了修改,RDB 是怎么做的呢?这里就要介绍下写时复制了。

写时复制技术

写时复制是操作系统提供的功能,Redis 在执行 RDB 快照时,依然能正常处理写操作。这样说可能不够明朗,详细点说说 bgsave 这个过程:



bgsave 子进程是由主线程 fork 生成的,而且可以共享主线程的所有内存数据。主线程和子进程 bgsave 是互不干扰的。

当主线程要修改一块数据,这块数据就会复制一份到副本上,然后主线程在这个副本上修改。同时呢,bgsave 子进程可继续将原来的数据写入 RDB 文件。这样就能某时刻快照的完整性,也不影响 redis 同时对当时数据的操作。

写到这,你是否认为 RDB 快照这样设计就完美了呢?答案是否定的。我们仔细想想,如果每次快照都是将全量数据备份,数据量大了之后,会有什么后果:

  • 全量数据写入 RDB 文件,磁盘压力增大。可能存在前一个快照没执行完,后一个又开始了。

  • bgsave 子进程虽不阻塞主线程,但它是由主线程 fork 出来的。fork 的过程是会阻塞主线程的。

基于这两大问题,Redis 提供了增量快照的方式。

RDB 增量快照

增量快照,就是指第一次全量快照后,后续 RDB 快照都是只记录修改过的数据记录,这样就可以避免很多开销。实现的方法就是 第一次全量快照后,数据修改后,会记录下来。这样在下一次增量快照时就知道哪些数据被修改了。

和 AOF 相比,RDB 快照恢复速度快。但是快照的频率设置需要注意了。如果设置的频率很高,宕机可能就会丢失较多数据;频率太低的话,开销也会很大。

AOF 和 RDB 混用

我们在考虑持久化时,肯定希望它恢复速度快,同时开销尽量小,而且尽量丢失少一点的数据。因此,在 Redis4.0 之后,支持了 AOF 和 RDB 混用的方式。

这种方式就是 RDB 以设定的频率执行,比如每 30 秒执行一次。然后没有执行快照的时间内,就用 AOF 日志去记录这段时间内的操作命令。这样一来,就解决了上述对持久化的期望。

小结

对于 RDB 快照和 AOF 文件,我们可根据实际需要去选择。提供一下选择参考:

  • 数据可靠性要求高,少丢失: 选择 RDB 快照和 AOF 混用;

  • 允许分钟级别的数据丢失: 可以只使用 RDB;

  • 只用 AOF:优先考虑 everysec 的配置(可靠性和性能之间的平衡)

发布于: 刚刚阅读数: 6
用户头像

还未添加个人签名 2020-06-16 加入

还未添加个人简介

评论

发布
暂无评论
你了解Redis RDB快照吗_redis_芥末拌个饭吧_InfoQ写作社区