Redis 持久化

简述

Redis的强劲性能很大程度上是由于其将所有数据都存储在了内存中，然而当Redis重启后，所有存储在内存中的数据就会丢失。在一些情况下，我们会希望 Redis 在重启后能够保证数据不丢失，例如：

  1. 将Redis作为数据库使用时。
  2. 将 Redis 作为缓存服务器，但缓存被穿透后会对性能造成较大影响，所有缓存同时失效会导致缓存雪崩，从而使服务无法响应。

这时我们希望 Redis 能将数据从内存中以某种形式同步到硬盘中，使得重启后可以根据硬盘中的记录恢复数据。这一过程就是持久化。

Redis支持两种方式的持久化，一种是RDB方式，另一种是AOF方式。

前者会根据指定的规则“定时”将内存中的数据存储在硬盘上，而后者在每次执行命令后将命令本身记录下来。两种持久化方式可以单独使用其中一种，但更多情况下是将二者结合使用。

对比优缺点

RDB 的优点

  • RDB 是一个非常紧凑的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

  • RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

  • RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork() 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

  • 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。

虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

  • 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF 的优点

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

AOF 的缺点

  • 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  • 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。
  • AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。

RDB 方式

RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上，这个过程即为“快照”。Redis会在以下几种情况下对数据进行快照：

  • 根据配置规则进行自动快照；
  • 用户执行 SAVE或 BGSAVE命令；
  • 执行 FLUSHALL命令；
  • 执行复制（replication）时。

（1） 根据配置规则进行自动快照

Redis允许用户自定义快照条件，当符合快照条件时，Redis会自动执行快照操作。

进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间窗口M和改动的键的个数N。每当时间M内被更改的键的个数大于N时，即符合自动快照条件。

在Redis配置文件中默认预置了3个条件：

save 900 1

save 300 10

save 60 10000

每条快照条件占一行，并且以 save 参数开头。同时可以存在多个条件，条件之间是“或”的关系。

就这个例子而言，save 900 1 的意思是在 15 分钟（900 秒）内有一个或一个以上的键被更改则进行快照。同理，save 300 10 表示在300秒内至少有10个键被修改则进行快照。

（2）用户执行 SAVE或 BGSAVE命令

除了让 Redis 自动进行快照外，当进行服务重启、手动迁移以及备份时我们也会需要手动执行快照操作。Redis提供了两个命令来完成这一任务。

1.SAVE命令

当执行SAVE命令时，Redis同步地进行快照操作，在快照执行的过程中会阻塞所有来自客户端的请求。当数据库中的数据比较多时，这一过程会导致 Redis 较长时间不响应，所以要尽量避免在生产环境中使用这一命令。

2.BGSAVE命令

需要手动执行快照时推荐使用 BGSAVE 命令。BGSAVE 命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应来自客户端的请求。执行 BGSAVE后Redis会立即返回 OK表示开始执行快照操作，如果想知道快照是否完成，可以通过 LASTSAVE命令获取最近一次成功执行快照的时间，返回结果是一个Unix时间戳，如：

redis> LASTSAVE 
(integer) 1423537869

（3）执行 FLUSHALL命令

当执行 FLUSHALL 命令时，Redis 会清除数据库中的所有数据。需要注意的是，不论清空数据库的过程是否触发了自动快照条件，只要自动快照条件不为空，Redis就会执行一次快照操作。

例如，当定义的快照条件为当1秒内修改10 000个键时进行自动快照，而当数据库里只有一个键时，执行FLUSHALL命令也会触发快照，即使这一过程实际上只有一个键被修改了。

当没有定义自动快照条件时，执行FLUSHALL则不会进行快照。

（4）执行复制时

当设置了主从模式时，Redis 会在复制初始化时进行自动快照。

快照原理

Redis默认会将快 照文件存储在Redis当前进程的工作目录中的dump.rdb文件中，可以通过配置 dir 和dbfilename 两个参数分别指定快照文件的存储路径和文件名。

快照的过程如下：

  1. Redis使用 fork() 函数复制一份当前进程（父进程）的副本（子进程）；
  2. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
  3. 当子进程写入完所有数据后会用该临时文件替换旧的 RDB 文件，至此一次快照操作完成。

【提示】

在执行 fork() 的时候操作系统（类 Unix 操作系统）会使用写时复制（copy -on- write）策略，即 fork() 函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录1000万个字符串类型键、大小为1 GB 的快照文件载入到内存中需要花费20～30秒。

通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。例如，使用Redis存储缓存数据时，丢失最近几秒的数据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

AOF 方式

AOF文件以纯文本的形式记录了Redis执行的写命令。

可以通过修改配置文件来打开 AOF 功能：

appendonly yes

从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。

这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速

度相较RDB会慢一些。

同步硬盘数据

在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地写入硬盘，

在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。

在 Redis 中我们可以通过 appendfsync 参数设置同步的时机，默认的配置是：

# appendfsync always
appendfsync everysec
# appendfsync no

默认情况下Redis采用 everysec 规则，即每秒执行一次同步操作。

always 表示每次执行写入都会执行同步，这是最安全也是最慢的方式。

no 表示不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），这是最快但最不安全的方式。

一般情况下使用默认值 everysec就足够了，既兼顾了性能又保证了安全。

AOF 的运作方式

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤：

  1. Redis 执行 fork() ，现在同时拥有父进程和子进程。
  2. 子进程开始将新 AOF 文件的内容写入到临时文件。
  3. 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
  4. 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  5. 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

从 RDB 方式切换到 AOF 方式

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

  1. 为最新的 dump.rdb 文件创建一个备份。
  2. 将备份放到一个安全的地方。
  3. 执行以下两条命令：
redis-cli> CONFIG SET appendonly yes

redis-cli> CONFIG SET save ""
  1. 确保命令执行之后，数据库的键的数量没有改变。
  2. 确保写命令会被正确地追加到 AOF 文件的末尾。

步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。

RDB 和 AOF，应该用哪一个？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但官方并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

参考资料：

《Redis 入门指南》（第二版） 李子骅 著

posted @ 2021-07-22 10:00  乐子不痞  阅读(55)  评论(0)  编辑  收藏  举报
回到顶部