Redis实战（二）Redis 的 RDB 配置和数据恢复

RDB 配置解释

在 redis.conf 文件中，默认有 RDB 持久化配置：

save 900 1
save 300 10
save 60 10000复制复制失败复制成功

解释：

• 这些配置称为检查点。

• 每隔 900s，如果有至少 1 个 key发生了变更，就生成一个新的 dump.rdb 文件，这个 dump.rdb 文件就是 redis 内存中完整的数据快照，也叫做 snapshotting。

• 同上，每隔 300s，检查是否有 10 个key 发生了变更，或者每隔 60s，检查是否有 10000个 key 发生了变更，如果有，则生成 dump.rdb 文件。

• 可以配置多项检查点。

• 可以移除所有检查点，只需要这样配置即可：save ""，或者移除所有配置项。

RDB 持久化的工作流程

（1）Redis 根据配置尝试生成 rdb 快照文件。

（2）Redis fork 一个子进程。

（3）子进程尝试将数据 dump 到一个临时的 RDB 快照文件中。

（4）完成快照后，就把临时文件替换掉之前生成的 RDB 文件。

RDB 实验

实验（1）测试 Redis 被 shutdown 时，Redis 是否会丢失数据。

首先重启 Redis，让检查点的时间窗口重置。

redis-cli shutdown
cd /etc/init.d
./redis_6379 start
ps -ef | grep redis复制复制失败复制成功

然后往 Redis 中插入几条数据：

redis-cli
set key1 abc
set key2 222
get key1
get key2复制复制失败复制成功

目前只设置了 2 个 key，且还没有到 900 s，所以不会触发自动生成 RDB 快照。

这个时候我们可以猜测下重启 redis 后，刚刚插入的两个 key 是否被持久化到 dump 文件中了。

我们来测试下：

重启 Redis，获取 key1 和 key2：

redis-cli shutdown
cd /etc/init.d
./redis_6379 start
ps -ef | grep redis
redis-cli
get key1
get key2复制复制失败复制成功

会看到 Redis 重启后还是存在 key1 和 key2，并不会丢失。

另外还可以找下 dump.rdb 文件，更新时间更新为 shutdown 的时间。

结论：shutdown 时，Redis 不会丢失丢失，会将内存中的数据立即生成一份完整 RDB 快照。

实验（2）用 kill -9 直接干掉 Redis，模拟 Redis 故障，验证数据是否会丢失。

首先插入几条新数据

redis-cli
set key3 333
set key4 444
get key3
get key4复制复制失败复制成功

然后获取 Redis 的进程 id

ps -ef | grep redis复制复制失败复制成功

Redis PID=1485，然后用 kill -9 干掉 Redis 进程：

kill -9 1485复制复制失败复制成功

然后重启 Redis

cd /var/run
rm -rf redis_6379.pid
cd /etc/init.d
./redis_6379 start复制复制失败复制成功

然后获取 key3 和 key4，发现没有这两个 key。

get key3
get key4复制复制失败复制成功

我们也可以查看下 dump.rdb 文件的更新时间是否有改变：

如果我们想要保证减少 Redis 故障导致的数据丢失，可以通过设置一个频率更高的检查点，每 5s 检查一次，如果有至少一条数据更新，则进行 RDB 快照。如下所示的配置：

save 5 1复制复制失败复制成功

但是如果故障正好发生在快照之前，那么变更的数据就没有生成到 RDB 文件中了。

而且生成的 RDB 的频率过高，而且变更的数据量很大的话，生成 RDB 的文件也会很大，操作 IO 的时间也会变长，长时间占用磁盘 IO 会造成性能问题。