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

在使用 Redis 的过程中，你是否遇到过下面这些问题：

• 开启 RDB 落盘，业务频繁出现请求超时。

• 除了 save 和 bgsave 命令，还有哪些操作会触发 RDB 落盘？

• 执行了 flushall，发现 flushall 之前写的数据又冒出来了。

• 重启 Redis 实例之后，发现数据有丢失的情况。

带着上面这些问题，我们一起来聊聊 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 111
OK
127.0.0.1:6301> set bbb 111
OK
127.0.0.1:6301> bgsave
Background saving started
127.0.0.1:6301> flushall
OK
127.0.0.1