redis(17):持久化-RDB方式

客官°小女子只卖身不卖艺 2022-10-30 09:23 192阅读 0赞

> Redis的强劲性能很大程度上是由于其将所有数据都存储在了内存中，然而当Redis重启 后，所有存储在内存中的数据就会丢失。

在一些情况下，我们会希望 Redis 在重启后能够保 证数据不丢失，例如：

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

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

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

--------------------

### 一、概述 ###

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

Redis会在以下几种 情况下对数据进行快照：

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

save 900 1 
    save 300 10 
    save 60 10000

每条快照条件占一行，并且以 save 参数开头。同时可以存在多个条件，条件之间 是“或”的关系。就这个例子而言，save 900 1 的意思是在 15 分钟（900 秒）内有一个或一个 以上的键被更改则进行快照。同理，save 300 10表示在300秒内至少有10个键被修改则进行快 照。

--------------------

### 二、根据配置规则进行自动快照 ###

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

进行快照的条件可以由`用户在配置文件中自定义`，由两个参数构成：`时间窗口M和改动的键的个数N`。每当时间M内被更改的键的个数大于N时，即符合自动快照条件。例如Redis安装目录 中包含的样例配置文件中预置的3个条件：

### 三、用户执行 SAVE或 BGSAVE命令 ###

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

1.  SAVE命令  
    当执行SAVE命令时，Redis同步地进行快照操作，在快照执行的过程中会阻塞所有来自 客户端的请求。当数据库中的数据比较多时，这一过程会导致 `Redis较长时间不响应，所以要尽量避免在生产环境中使用这一命令`。
2.  BGSAVE命令  
    需要手动执行快照时推荐使用 BGSAVE 命令。`BGSAVE 命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应来自客户端的请求`。执行 BGSAVE后Redis会立即 返回 OK表示开始执行快照操作，如果想知道快照是否完成，可以通过`LASTSAVE命令获取最近一次成功执行快照的时间`，返回结果是一个Unix时间戳，如：

redis> LASTSAVE 
    (integer) 1423537869

--------------------

### 四、执行 FLUSHALL命令 ###

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

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

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

--------------------

### 五、执行复制时 ###

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

这里只需要了解当使用复制操作时，即使没有定义自动快照条 件，并且没有手动执行过快照操作，也会生成RDB快照文件。

--------------------

### 六、快照原理 ###

> 理清Redis实现快照的过程对我们了解快照文件的特性有很大的帮助。Redis默认会将快 照文件存储在Redis当前进程的工作目录中的dump.rdb文件中，可以通过配置`dir和dbfilename` 两个参数分别指定快照文件的存储路径和文件名。

快照的过程如下:

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

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

> 写时复制策略也保证了在 fork的时刻虽然看上去生成了两份内存副本，但实际上内存的 占用量并不会增加一倍。这就意味着当系统内存只有2 GB，而Redis数据库的内存有1.5 GB 时，执行 fork后内存使用量并不会增加到3 GB（超出物理内存）。为此需要确保 Linux 系统 允许应用程序申请超过可用内存（物理内存和交换分区）的空间，方法是在`/etc/sy sctl.conf 文件加入 vm.overcommit_memory = 1`，然后重启系统或者执行 sysctl vm.overcommit\_memory=1 确保设置生效。

> 另外需要注意的是，当进行快照的过程中，如果写入操作较多，造成 fork前后数据差异 较大，是会使得内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前的数据库 数据，而且还保存着 fork时刻的内存数据。进行内存用量估算时很容易忽略这一问题，造成 内存用量超限。

通过上述过程可以发现`Redis在进行快照的过程中不会修改RDB文件`，只有快照结束后才 会将旧的文件替换成新的，也就是说`任何时候 RDB 文件都是完整的`。这使得我们可以通过 定时备份 RDB 文件来实现 Redis 数据库备份。RDB 文件是经过压缩（可以配置 rdbcompression 参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存 中的数据大小，更加利于传输。

--------------------

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录1000万个字符串类型键、大小为1 GB 的 快照文件载入到内存中需要花费20～30秒。  
通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有 数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发 生的数据损失控制在能够接受的范围。例如，使用Redis存储缓存数据时，丢失最近几秒的数 据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到 最小，则可以使用AOF方式进行持久化。