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 会造成性能问题。