experience数据库redis

9-redis-可用性-持久化

文章目录
  1. 1. Redis 中的两种持久化方式
    1. 1.1. 方式一：快照
      1. 1.1.1. COW-fork
      2. 1.1.2. AOF(类似Bin log)
        1. 1.1.2.1. 瘦身
        2. 1.1.2.2. fsync
    2. 1.2. Redis 4.0混合持久化
    3. 1.3. RDB 和 AOF 各自有什么优缺点？
      1. 1.3.0.1. RDB | 优点
      2. 1.3.0.2. RDB | 缺点
      3. 1.3.0.3. AOF | 优点
      4. 1.3.0.4. AOF | 缺点
  2. 1.4. ■两种方式如何选择？
  3. 1.5. ■Redis 的数据恢复

Redis 中的两种持久化方式

方式一：快照

操作系统多进程 COW(Copy On Write) 机制 拯救了我们。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段：

COW-fork

为什么 fork 成功调用后会有两个返回值呢？ 因为子进程在复制时复制了父进程的堆栈段，所以两个进程都停留在了 fork 函数中 *(都在同一个地方往下继续”同时”执行)*，等待返回，所以 一次在父进程中返回子进程的 pid，另一次在子进程中返回零，系统资源不够时返回负数。

快照持久化 可以完全交给 子进程 来处理，父进程 则继续 处理客户端请求。子进程 做数据持久化，它 不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是 父进程 不一样，它必须持续服务客户端请求，然后对 内存数据结构进行不间断的修改。

使用操作系统的 COW 机制来进行 数据段页面 的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复 制一份分离出来，然后 对这个复制的页面进行修改。这时 子进程 相应的页面是 没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化 叫「快照」的原因。

AOF(类似Bin log)

AOF(Append Only File - 仅追加文件) 它的工作方式非常简单：每次执行 修改内存 中数据集的写操作时，都会 记录 该操作。假设 AOF 日志记录了自 Redis 实例创建以来 所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例 顺序执行所有的指令，也就是 「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

Redis 收到客户端修改指令后，会先进行参数校验、逻辑处理，如果没问题，就 立即 将该指令文本 存储 到 AOF 日志中，也就是说，先执行指令再将日志存盘。这一点不同于 MySQL、LevelDB、HBase 等存储引擎，如果我们先存储日志再做逻辑处理，这样就可以保证即使宕机了，我们仍然可以通过之前保存的日志恢复到之前的数据状态，但是 Redis 为什么没有这么做呢？

由于AOF文件会比较大，为了避免写入无效指令（错误指令），必须先做指令检查？如何检查，只能先执行了。因为语法级别检查并不能保证指令的有效性，比如删除一个不存在的key。而MySQL这种是因为它本身就维护了所有的表的信息，所以可以语法检查后过滤掉大部分无效指令直接记录日志，然后再执行。

瘦身

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其 原理 就是 开辟一个子进程 对内存进行 遍历 转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的 增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

fsync

我们需要借助 glibc 提供的 fsync(int fd) 函数来讲指定的文件内容 强制从内核缓存刷到磁盘。但 “强制开车” 仍然是一个很消耗资源的一个过程，需要 **”节制”**！通常来说，生产环境的服务器，Redis 每隔 1s 左右执行一次 fsync 操作就可以了。

Redis 4.0混合持久化

为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小：

图片

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

RDB 和 AOF 各自有什么优缺点？

RDB | 优点

  1. 只有一个文件 dump.rdb，方便持久化。
  2. 容灾性好，一个文件可以保存到安全的磁盘。
  3. 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以使 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能
  4. 相对于数据集大时，比 AOF 的 启动效率 更高。

RDB | 缺点

  1. 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 Redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候；

AOF | 优点

  1. 数据安全，aof 持久化可以配置 appendfsync 属性，有 always。RDB五分钟一次生成快照，但是AOF everyonesec 一秒一次去通过一个后台的线程 fsync操作，那最多丢这一秒的数据。
  2. 以 append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。
  3. AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）

AOF | 缺点

  1. AOF 文件比 RDB 文件大，且 恢复速度慢。
  2. 数据集大 的时候，比 rdb 启动效率低。

■两种方式如何选择？

  • 一般来说， 如果想达到足以媲美 PostgreSQL 的 数据安全性，你应该 同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
  • 如果你非常关心你的数据， 但仍然 可以承受数分钟以内的数据丢失，那么你可以 只使用 RDB 持久化。
  • 有很多用户都只使用 AOF 持久化，但并不推荐这种方式，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免 AOF 程序的 bug。
  • 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

■Redis 的数据恢复

Redis 的数据恢复有着如下的优先级：

  1. 如果只配置 AOF ，重启时加载 AOF 文件恢复数据；
  2. 如果同时配置了 RDB 和 AOF ，启动只加载 AOF 文件恢复数据；
  3. 如果只配置 RDB，启动将加载 dump 文件恢复数据。

拷贝 AOF 文件到 Redis 的数据目录，启动 redis-server AOF 的数据恢复过程：Redis 虚拟一个客户端，读取 AOF 文件恢复 Redis 命令和参数，然后执行命令从而恢复数据，这些过程主要在 loadAppendOnlyFile() 中实现。

拷贝 RDB 文件到 Redis 的数据目录，启动 redis-server 即可，因为 RDB 文件和重启前保存的是真实数据而不是命令状态和参数。