上一篇中，我们说了Redis持久化的一些相关理论知识。今天，我们详细学习一下RDB持久化机制的实战。
一、如何配置RDB持久化机制
配置RDB持久化很简单，就是在redis.conf文件中配置save命令行。如下：
默认情况下，redis给出如上的配置。以save 60 10000举例说明，它表示：每隔60s，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照。
当然我们也可以手动调用save或者bgsave命令分别同步或者一步执行rdb快照生成。
可以看到，save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有就生成一个新的dump.rdb文件。
二、RDB持久化机制的工作流程
（1）redis根据配置自己尝试去生成rdb快照文件。
（2）fork一个子进程出来。
（3）子进程尝试将数据dump到临时的rdb快照文件中。
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件。
三、实战
1、在redis中保存几条数据，立即停掉redis进程，然后重启redis，看看刚才插入的数据还在不在。
（1）首先我们进入/var/redis/6379目录，可以看到该目录下还没有rdb文件。
（2）进入redis cli交互命令行，并设置一个键值对，然后立即停掉redis进程。
（3）重启redis服务，看看刚刚的键值对是否被持久化。
可以看到k1的值还在，为什么？理论上来说，我们在设置了k1的值后是立即停掉redis进程的，还没到 snapshotting检查点，但是我们可以看到在/var/redis/6379目录下，确实生成了一个dump.rdb文件。
其实，在这里，我们通过redis-cli SHUTDOWN方式去停掉redis进程，这是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。请看第2点的演示。
2、在redis中再保存几条新的数据，立即用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景。
（1）现在dump.rdb中有一个k1的值，我们现在增加一个k2的值，然后通过kill -9命令直接杀死进程。
（2）重启redis服务， 看看刚刚的k2是否被持久化。可以看到k2的值没有被持久化，由于k1已经在dump.rdb中被持久化，所以k1的值仍然在。
3、手动设置一个save检查点，然后通过kill -9粗暴杀死redis进程，模拟redis故障异常退出。
（1）我们设置一个检查点，每5s有一个值发生变更，就生成一个新的dump.rdb文件。
（2）删除已经存在dump.rdb文件，并重启redis。
（3）设置k1的值，然后过5s后，通过kill -9杀死进程。
（4）重启redis服务， 看看刚刚的k1是否被持久化。可以看到k1的值在5s后被持久化，即使通过kill -9暴力停止redis服务，仍然被写入dump.rdb中。
