RDB，就是把内存数据以快照的形式保存到磁盘上。 一、Redis DataBase RDB在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中。 redis会单独创建fork子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。fork的作用是复制一个与当前进程一样的进程，新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。 RDB的缺点是最后一次持久化的数据可能丢失
二、配置的位置
find / -name dump.rdb 发现有两个dump文件，这两个文件目录不一致，问题在于 redis.conf 文件属性dir，默认配置是dir ./ 表示在哪启动server时候的时候，dump.rdb就在哪生成
重点是 dir 的默认配置一定要改，改成确定路径，编辑redis.conf 设置 dir /data/redis-3.2.11/，这样启动服务时dump文件会固定在/data/redis-3.2.11目录下了
三、触发RDB快照 使用配置文件中默认的快照配置，可以拷贝生成的dump.rdb文件用于恢复数据。 执行save或者bgsave可以立即进行备份，生成新的dump.rdb文件。save命令只管保存，其它不管，阻塞住其它全部操作。bgsave命令会使得redis在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。 执行flushall命令也会产生dump.rdb文件，但是命令执行后数据清空，备份的也都是空数据，没有意义。
四、恢复数据
- 将备份文件
dump.rdb文件移动到redis安装目录并启动服务，就会自动读取上一次的备份文件里面的数据。 - 执行
config get dir可以获取目录的地址。
五、RDB优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
六、RDB劣势
- 在一定间隔时间做一次备份，所以如果redis发生意外，就会丢失最后一次快照后的所有修改。
- fork子进程执行的时候，内存中的数据被克隆了一份，大致2倍的膨胀性。
redis中的RDB持久化详解
- 如何在redis中配置RDB持久化文件
在redis持久化中 默认是开启RDB模式的。这里我们只需要对RDB进行配置即可
在上面有三个配置选项 分别是
每隔900秒 有一条key进行变更
每个300秒 有10条key进行变更
没隔60秒 有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快照文件的生成之后，那么就会替换以前的老快照。
3、基于RDB持久化机制的数据恢复实验数据还在，为什么？
我们在redis中存入几条数据
在使用redis-cli SHUTDOWN 停掉redis
这个时候我们进入到存放快照的目录进行查看。
可以看到数据依旧是存在的。
带出来一个知识点，通过redis-cli SHUTDOWN这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照
/var/redis/6379/dump.rdb
（2）在redis中再保存几条新的数据，用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景这次就发现，redis进程异常被杀掉，数据没有进dump文件，几条最新的数据就丢失了
使用 kill -9 的方式杀掉redis进程。
在进入到存放快照的文件目录查看快照文件 并没有进行生成。
（3） 我们这里在做一个实验，重新对conf文件进行配置，配置成每五秒进行一次快照，在进行一次实验
设置成 没五秒有1个key进行变更那么就会生成新的dump.db文件
使用kill杀死进程过后 我们可以看到快照文件是生成了的
