Redis技术知识总结之六——Redis持久化机制

接上篇《Redis技术知识总结之五——Redis集群模式》

六. Redis 持久化机制

参考地址：《Redis持久化机制》

Redis 有两种持久化机制：快照 (RDB) 和 AOF 日志。其中快照是一次性全量备份，AOF 是增量备份。

6.1 快照 (RDB)

Redis 使用操作系统的多进程 COW (Copy On Write) 机制实现快照持久化。在持久化时，由于要一边要持久化，一边又要满足 Redis 的正常使用，所以 Redis 在持久化的时候，使用了 glibc 的 fork 函数产生了一个子进程，在子进程中进行快照持久化操作，主进程满足业务的正常使用。

RDB的原理是fork和cow。fork是指redis通过创建子进程来进行RDB操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

快照持久化的内存策略是：子进程按照数据页进行复制。在持久化过程中，子进程负责持久化过程，它将主进程数据段的数据页复制一份出来，然后对原数据页进行存储；同一时间，主进程对那份复制出来的数据进行操作。通过复制小数据量数据页（通常每个数据页只有 4KB）的方式，保证了主进程修改数据不会影响子进程存储，子进程存储的数据，还是子进程产生一瞬间的数据。

快照触发方式有自动触发与手动触发两种。

• 自动触发：通过 redis.conf 配置文件进行配置；
• 手动触发：
  • save: 阻塞式触发，在未完成前，客户端无法进行命令操作；
  • bgsave: 非阻塞式触发，主进程 fork 出子进程进行备份操作；

在恢复文件时，将备份文件 (dump.rdb) 放在 Redis 安装目录，然后启动 Redis，就能把 RDB 中的文件加载到 Redis 服务中。

快照存储的优点缺点：

• 优点：
  • 数据结构紧凑，保存了 Redis 服务在某个时间点上的数据集，非常适合做备份和灾难恢复；
  • 进行 RDB 快照持久化时，主进程会 fork 出一个子进程进行备份工作，主进程不需要额外的 IO 操作；
  • RDB 恢复大数据集时，速度比 AOF 快；
• 缺点：
  • 版本兼容问题：Redis 版本更新过程中有多个 RDB 版本，存在老版 RDB 兼容性无法兼容新版的问题；
  • 无法做到实时持久化，因为 bgsave 时的 fork 操作每次都会创建子进程，内存中的数据被克隆了一份，属于重量级操作。

6.2 AOF

AOF 日志存储的是 Redis 服务器的顺序指令序列，它只记录对内存进行修改的指令记录。AOF 使用追加记录的方式，在 Redis 长期运行的过程中，AOF 日志会越来越长，所以一旦宕机重启载入 AOF 日志，将会是一个非常耗时的功能，因此我们需要对 AOF 进行瘦身，即 AOF 重写。

AOF 重写并不是对原始的 AOF 文件进行重新整理，而是 fork 一个子进程遍历服务器的键值对，转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后，将原来的文件替换为序列化后的文件即可。

AOF 重写分为两个过程，一个是 fork 子进程重写过程执行的原始数据内容，另一个是在 fork 过程中主进程修改的指令。

6.3 混合持久化

Redis 4.0 之后加入了新的持久化选项：混合持久化。它将 RDB 和 AOF 内容放在一起，其中 AOF 日志记录的不是全量日志，而是持久化开始到持久化结束时间内的 AOF 日志（通常该部分日志很小）。

6.4 AOF 的持久化策略

问：如果突然机器掉电会怎样？

AOF 的持久化策略：AOF 日志是以文件形式存在的，里面记录的是内存的操作记录，它的实现是将操作系统内核为文件描述符分配的内存缓存，通过异步的方式刷新到数据磁盘中。这种操作是 glibc 的 fsync 操作，它是一个很慢的操作，与 Redis 的高性能是相反的。

AOF 提供了三种持久化策略：

• no: 无 fsync，由系统保证数据刷新到磁盘，速度最快，但很不安全（通常不使用）；
• always: 每次 fsync，每一个修改内存的 Redis 指令都会执行一次 fsync，速度很慢（通常不使用）；
• everysec: 每秒进行一次 fsync，有可能丢失一秒的 fsync 的数据。通常选择 everysec 策略，兼顾安全性和效率。

持久化取决于 AOF 日志 sync 属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。