真枪实弹，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 会造成性能问题。
