Redis 持久化机制

Apr 13, 2020

本文参考：这里

RDB

RDB 持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘，是默认的持久化方式
这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb

可以通过配置设置 Redis 在 n 秒内如果超过 m 个 key 被修改就自动做快照，比如：

save 900 1     #900秒内如果超过1个key被修改，则发起快照保存
save 300 10    #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000

保存过程

  1. Redis fork 出一个子进程
  2. 父进程继续处理 Client 请求，子进程负责将内存内容写入到临时文件。由于 OS 的写时复制机制（copy on write），父子进程会共享相同的物理页面，当父进程处理写请求时 OS 会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是 fork 时刻整个数据库的一个快照
  3. 子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出

Client 也可以使用 save 或者 bgsave 命令通知 Redis 做一次快照持久化。save 操作是在主线程中保存快照的，由于 Redis 是用一个主线程来处理所有 Client 的请求，这种方式会阻塞所有 Client 请求，所以不推荐使用。

需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是只同步增量数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘 I/O 操作，可能会严重影响性能。

优势

  1. 方便备份。RDB 方式整个 Redis 数据库只包含一个文件，这样非常方便进行备份
  2. 方便迁移。很容易将一个 RDB 文件移动到其他的存储介质上
  3. 恢复速度快。RDB 方式在恢复大数据集时的速度比 AOF 的恢复速度要快
  4. 对性能影响小。父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

劣势

  1. RDB 方式不适合保存实时数据，即有大概率在服务器故障时丢失数据。虽然 Redis 允许设置不同的保存点（save point）来控制保存 RDB 文件的频率，但是，因为 RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此可能会至少 5 分钟才保存一次 RDB 文件。在这种情况下，一旦发生故障停机，就可能会丢失好几分钟的数据。
  2. 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时，fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork()，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF

保存过程

Redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)
当 Redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容

可以配置 Redis 通过 fsync 函数强制 OS 写入到磁盘的时机
有如下三种方式：

appendonly yes			//启用aof持久化方式
# appendfsync always	//每次收到写命令就立即强制写入磁盘，可保证完全的持久化，但性能最差，不推荐
appendfsync everysec	//每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，默认方式，推荐
# appendfsync no		//完全依赖os，性能最好，持久化没保证

由于 AOF 方式是持续追加命令到持久化文件中，因此会导致持久化文件越来越大
例如调用 incr test 命令 100 次，文件中必须保存全部的 100 条命令，其实有99条都是多余的，因为要恢复数据库的状态其实文件中保存一条set test 100 就够了
为了压缩 AOF 的持久化文件，Redis 提供了 bgrewriteaof 命令
收到此命令后，Redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下：

  1. Redis fork 出一个子进程
  2. 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
  3. 父进程继续处理 Client 请求，除了把写命令写入到原来的 AOF 文件中，同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败也不会出问题
  4. 当子进程把快照内容以命令方式写到临时文件中后，子进程发信号通知父进程，然后父进程把缓存的写命令也写入到临时文件
  5. 父进程使用临时文件替换老的 AOF 文件，并重命名
  6. 后续写命令往新的 AOF 文件中追加

需要注意的是重写 AOF 文件的操作并没有读取旧的 AOF 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 AOF 文件，这点和快照有点类似

优势

  1. 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync，每秒钟一次 fsync，或者每次执行写入命令时 fsync。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
  2. AOF 文件是一个只进行追加操作的日志文件（append only log），因此对 AOF 文件的写入不需要进行 seek，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof 工具也可以轻易地修复这种问题。 Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
  3. AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export）AOF 文件也非常简单：举个例子，如果不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

劣势

  1. 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  2. 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
  3. AOF 在过去曾经发生过这样的 bug：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug。）测试套件里为这种情况添加了测试：它们会自动生成随机的、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。

总结

  1. 一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，应该同时使用两种持久化功能
  2. 如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化
  3. 其余情况推荐 AOF