Redis之持久化

蔚落 2022-05-08 00:42 328阅读 0赞

Redis支持RDB和AOF两种持久化机制。

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，可以通过手动和自动两种方式进行RDB持久化。

触发方式

  • 手动触发























命令 执行流程 执行进程 阻塞
save 阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用 ,由于该命令会阻塞Redis服务进程，因此已被废弃，更多的还是使用bgsave 父进程处理 阻塞
bgsave Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。bgsave是当前主流触发RDB持久化的方式 子进程处理 只有fork阶段阻塞，其余由子进程处理不会阻塞
  • 自动触发
  1. 使用save相关配置，如save m n。表示m秒内数据集存在n次修改 时，自动触发bgsave。
  2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
  3. 执行debug reload命令重新加载Redis时，也会自动触发save操作。
  4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

执行流程

在这里插入图片描述

如下是bgsave的主要方法的执行逻辑：

  1. 执行bgsave命令， Redis父进程判断当前是否存在正在执行的子进程， 如RDB/AOF子进程， 如果存在直接返回
  2. 父进程执行fork操作创建子进程， fork操作过程中父进程会阻塞
  3. 父进程fork完成后， bgsave命令返回“Background saving started”信息并不再阻塞父进程， 可以继续响应其他命令
  4. 子进程创建RDB文件， 根据父进程内存生成临时快照文件， 完成后对原有文件进行原子替换
  5. 进程发送信号给父进程表示完成， 父进程更新统计信息

rdb相关参数






















命令 功能
info stats命令查看latest_fork_usec 获取最近一个fork操作的耗时， 单位为微秒
lastsave命令查看rdb_last_save_time 获取最后一次生成RDB的时间
info persistence命令查看rdb*相关参数 -

优点

  • RDB是一个紧凑压缩的二进制文件， 代表Redis在某个时间点上的数据快照。 非常适用于备份， 全量复制等场景进行有效灾备。
  • 由于是紧凑压缩的二进制文件，因此Redis加载RDB恢复数据远远快于AOF的方式。

缺点

  • 数据无法实时持久化/秒级持久化。 因为bgsave每次运行都要执行fork操作创建子进程， 属于重量级操作， 频繁执行成本过高。
  • 存在老版本无法兼容新版RDB格式。RDB文件使用特定二进制格式保存，演进过程中有多个格式的RDB版本。

AOF

AOF（append only file）与RDB保持数据库键值对对象的二进制文本不同，它采用记录Redis的文本格式命令的形式进行持久化。

执行频率

可以通过appendfsync控制


































参数值 执行效果 刷盘策略 性能 数据安全
always 每次写入都要同步AOF文件，在一般的SATA硬盘 上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置 命令写入aof_buff缓冲区后立刻调用系统fsync进行刷盘进行持久化后返回 低 高
everysec 建议的同步策略，也是默认配置，做到兼顾性能和 数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。（严格来说最多丢失1秒数据是不准确的) 命令写入aof_buff缓冲区后，调用系统write后返回，由专门线程控制调用fsync进行刷盘持久化 一般 较安全
no 由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证 命令写入aof_buff缓冲区后，调用系统write后返回，刷盘由操作系统控制，一般同步周期为30秒 高 低

write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓 冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将 阻塞直到写入硬盘完成后返回，保证了数据持久化
感兴趣的话，可以参考下mysql的刷盘机制进行对比

执行流程

AOF的执行流程主要有：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

在这里插入图片描述

  1. 所有的写入命令会追加到aof_buf（缓冲区）中。
  2. AOF缓冲区根据对应的策略向硬盘做同步操作。
  3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩 的目的。
  4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

重写压缩

随着命令不断写入AOF，文件会越来越大，为了减少存储占用和更快地在重启阶段加载Redis，Redis 引入AOF重写机制压缩文件体积。

压缩文件空间的来源：

  • 过期数据不再写入
  • 覆盖重复执行命令后只保留最终命令。如set key aaa，set key bbb
  • 合并命令，如lpush list a、lpush list b、lpush list c可以转化为lpush list a b c

触发机制

如下图，是重写压缩的执行流程

在这里插入图片描述

  • fork子进程处理aof文件重写工作
  • 父进程接收命令后会双写aof_buff、aof_rewrite_buff这两块缓冲区，以确保重写过程也可以接收新命令，防止命令丢失
  • 最终新重写压缩的AOF文件会覆盖旧AOF文件，达到节省空间的目的

重写机制的触发也分为手动和自动两种。

  • 手动触发

直接调用bgrewriteaof命令。

  • 自动触发

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

  • auto-aof-rewrite-min-size 表示运行AOF重写时文件最小体积，默认 为64MB。
  • auto-aof-rewrite-percentage 代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比 值。
  • 自动触发时机 = aof_current_size>auto-aof-rewrite-min- size &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite- percentage

优缺点

  • 优点

    • 基于Redis命令文本格式，有较好的可读性
    • 不需要像rdb那样进行序列化二次处理，实现简单
    • 提供了较为灵活的appendfsync刷盘策略控制

  • 缺点

    • 直接存储，没有进行压缩，占用空间大（但是也提供了rewrite机制进行压缩控制）
    • 由于是文本命令的直接操作回放，重载恢复数据比rdb时间长

重启加载

如下是重启加载持久化文件数据到内存的执行流程，会优先加载AOF文件，如果加载不成功会尝试加载RDB文件

  1. /* Function called at startup to load RDB or AOF file in memory. */
  2. void loadDataFromDisk(void) {
  3.     // 记录开始时间
  4.     long long start = ustime();
  6.     // AOF 持久化已打开？
  7.     if (server.aof_state == REDIS_AOF_ON) {
  8.         // 尝试载入 AOF 文件
  9.         if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)
  10.             // 打印载入信息，并计算载入耗时长度
  11.             redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);
  12.     // AOF 持久化未打开
  13.     } else {
  14.         // 尝试载入 RDB 文件
  15.         if (rdbLoad(server.rdb_filename) == REDIS_OK) {
  16.             // 打印载入信息，并计算载入耗时长度
  17.             redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",
  18.                 (float)(ustime()-start)/1000000);
  19.         } else if (errno != ENOENT) {
  20.             redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));
  21.             exit(1);
  22.         }
  23.     }
  24. }

总结

  • 基于rdb文件的bgsave和基于aof文件的bgrewriteaof会彼此阻塞，当有一方执行时另一方被禁止执行，双方都是通过fork子进程进行的并不存在冲突，这里只是性能考虑而这样进行设计的
  • Redis无论在哪种持久化机制下，即使在Redis中最可靠的持久化方式也无法保证100%可靠，只能是相对可靠。当appendfsync刷盘策略开启为always可以保证每次写入缓冲区后立刻调用fsync刷盘持久化，但是这并不是一个原子性操作，中间出现异常便持久化失败
  • 我们通常会充分利用Redis的高性能，把它作为一个支持多种数据结构的纯缓存中间件来进行使用，一般情况下为了追求高性能会牺牲持久性方面的考虑

发表评论

表情：
评论列表 （有 0 条评论，328人围观）

还没有评论，来说两句吧...

相关阅读

    相关 Redis持久化之AOF

    Redis持久化之AOF Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF 则是通过保存Redis服务器所执行的写

    ゝ一世哀愁。ゝ一世哀愁。/ 0 赞/ 250 阅读

    相关 Redis持久化之RDB

    Redis持久化之RDB 由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容

    以你之姓@以你之姓@/ 0 赞/ 275 阅读

    相关 Redis持久化之RDB

    原文链接：[点击打开链接][Link 1] RDB[¶][Link 2] 在运行情况下， Redis 以数据结构的形式将数据维持在内存中， 为了让这些

    女爷i女爷i/ 0 赞/ 285 阅读

    相关 Redis持久化之AOF

    > RDB从整体上来说，已经很棒了，备份速度快，备份文件小，cpu性能也充足的用上了。但是最后的那一次备份是可能会丢失的。对于程序员来说，越是厉害的程序员强迫症越是强，不容有那

    水深无声水深无声/ 0 赞/ 280 阅读

    相关 Redis之持久化

    Redis支持`RDB`和`AOF`两种持久化机制。 RDB `RDB`持久化是把当前进程数据生成快照保存到硬盘的过程，可以通过`手动`和`自动`两种方式进行RDB持久

    蔚落蔚落/ 0 赞/ 329 阅读