知道 Redis RDB 这些细节，可以少踩很多坑

带着上面这些问题，我们一起来聊聊 RDB 的一些细节。

触发 RDB 文件创建的命令有两条，save 和 bgsave。

save 我们知道会阻塞整个实例，通常也不太可能会用。

bgsave 命令是在后台生成 RDB 文件，Redis 仍然可以处理客户端请求。

但是并不能保证 bgsave 不会影响 Redis 所有的客户端请求，在生成 RDB的过程中，Redis 会 fork 出一个子进程，子进程和父进程会共享内存地址空间，可以保证子进程拥有父进程相同的内存数据。但是在 fork 子进程时，操作系统需要将父进程的内存页表复制给子进程。如果整个 Redis 实例占用的内存很大，那么它的内存页表也会很大，复制的时间也会比较长。

同时，这个过程会消耗大量的 CPU 资源，在复制完成之前，父进程也会被阻塞，无法处理客户端请求。

执行 fork 后，子进程可以扫描 Redis 中所有数据，然后将所有数据写入 RDB 文件。

之后，父进程仍然处理客户端的请求。父进程在处理写命令时，会重新分配新的内存地址空间，向操作系统申请新的内存使用，不再与子进程共享。这样，父子进程的内存会逐渐分离，父进程会申请新的内存空间并改变内存数据，子进程的内存数据不会受到影响。

可以看出，在生成RDB文件时，不仅消耗CPU资源，还需要消耗更多的内存空间。

上面也就是“开启 RDB 落盘，业务频繁出现请求超时”的原因。通常在生产环境，我们也应该避免在 master 实例上做 RDB。

那么除了 save 和 bgsave 命令，还有哪些常见会触发 RDB 呢？这里就来总结几种情况，这也是问题“除了 save 和 bgsave 命令，还有哪些操作会触发 RDB 落盘呢？”的答案：

1 配置了 RDB 落盘的情况

比如配置文件配置了 save xxx xxx，或者命令行执行了 config set save "xxx xxx"，都表示配置了 RDB 落盘。

比如配置了 save 900 1

则表示 900 秒内如果至少有 1 个 key 的值变化，则做一次 bgsave。

我们在前面有提到 bgsave 也会对客户端请求有所影响，所以不建议在 master 上增加该参数，如果为了数据备份，建议只在 slave 增加 save 参数。

2 主从复制

第一次创建主从复制关系时，会在主库执行 bgsave 命令生成 RDB 文件，然后传给从库，从库加载 RDB 文件，以完成一次全量数据的传输。

因此在业务访问高峰，并且数据量比较大的情况，不建议在 master 上创建 slave。

3 Redis 在执行 flushall 命令

配置了 RDB 落盘的情况，在执行 flushall 命令时，会进行一次 RDB 落盘，但是内容是空的。目的是将 RDB 文件也清空。

但是，如果 RDB 和 AOF 都关闭的情况下，会有下面这种情况：

127.0.0.1:6301> set aaa 111OK127.0.0.1:6301> set bbb 111OK127.0.0.1:6301> bgsaveBackground saving started127.0.0.1:6301> flushallOK127.0.0.1:6301> config get save"save"""127.0.0.1:6301> config get appendonly"appendonly""no"127.0.0.1:6301> shutdown

再启动 Redis

127.0.0.1:6301> keys *"aaa""bbb"

会看到我们清空 Redis 之前写入的数据。显然是不符合逻辑的。

这是因为在启动 Redis 时，会加载数据目录下的 RDB 文件，而这个 RDB 文件是 flushall 之前执行 bgsave 生成的，也就是会看到清空 Redis 之前写入的数据。这里也是“执行了 flushall，发现 flushall 之前写的数据又冒出来了”的原因。

所以在实例未开启 RDB 和 AOF 的情况下，如果执行了 flushall 命令，建议再执行一次 bgsave，让 RDB 文件也清空。

另外还测试了开启 AOF，关闭 RDB 的情况：

127.0.0.1:6301> set aaa 111OK127.0.0.1:6301> set bbb 111OK127.0.0.1:6301>  bgsaveBackground saving started127.0.0.1:6301> flushallOK127.0.0.1:6301> config get save"save"""127.0.0.1:6301> config get appendonly"appendonly""yes"127.0.0.1:6301> shutdown

启动 Redis

127.0.0.1:6301> keys *(empty list or set)

重启之后不会再看到 flushall 之前写入的数据，因为 Redis 在启动时加载 RDB 文件后，也会加载在执行 RDB 之后 AOF 里新增的操作。而 flushall 操作就记录在 AOF 文件中。

4 正常关闭时

我们通过在命令行执行 shutdown 正常关闭 Redis 时，并不是所有情况都会执行一次 RDB 落盘的，这里就来分析一下不同配置，重启后的情况。

4.1 AOF 和 RDB 都开启的情况

127.0.0.1:6301> set bbb 111OK127.0.0.1:6301> config get save"save""1800 1"127.0.0.1:6301> config get appendonly"appendonly""yes"127.0.0.1:6301> shutdown

启动 Redis

127.0.0.1:6301> get bbb"111"

这种情况会在关闭时执行一次 RDB 落盘，启动时加载 RDB 文件，保证重启前后数据一致。

4.2 AOF 和 RDB 都未开的情况

127.0.0.1:6301> set ccc 111OK127.0.0.1:6301> config get save"save"""127.0.0.1:6301> config get appendonly"appendonly""no"127.0.0.1:6301> shutdown

然后启动 Redis

127.0.0.1:6301> get ccc(nil)

发现重启之前 ccc 的 key 已经丢失，因此在 master 未开启 RDB 的情况，关闭之前需要主动执行 bgsave，否则会导致数据丢失。这也是“重启 Redis 实例之后，发现数据有丢失的情况”的原因。

4.3 AOF 关闭，RDB 开启的情况

127.0.0.1:6301> set ddd 111OK127.0.0.1:6301> config get save"save""1800 1"127.0.0.1:6301> config get appendonly"appendonly""no"127.0.0.1:6301> shutdown

启动 Redis

127.0.0.1:6301> get ddd"111"

这种情况会写 RDB，重启后数据未丢失。

4.4 AOF 开启，RDB 关闭的情况

127.0.0.1:6301> set eee 111OK127.0.0.1:6301> config get save"save"""127.0.0.1:6301> config get appendonly"appendonly""yes"127.0.0.1:6301> shutdown

启动 Redis

127.0.0.1:6301> get eee"111"

这种情况尽管不会进行 RDB 落盘，但是因为之前的操作都写入了 AOF，在 Redis 启动时，会加载 AOF 里的数据，因此也会跟关闭之前的数据保持一致。