RDB（Redis DataBase）
在指定的时间间隔内将内存中的数据集快照写入磁盘
也就是行话讲的snpashot 快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中， 待持久化过程都结束了，在用这个临时文件替换上一次持久化好的文件。
整个过程中，主进程是不会进行任何IO操作的。这就确保了极高的性能。
如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
Frok:
Fork 的作用是复制一个与当前进程一样的进程，新的进程的所有的数据（变量，环境变量，程序计数器等）
数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
dump.rdb
(重点学习恢复策略)
误操作导致的数据消失，重启以后重新启动将会恢复数据，将数据重新读取到内存。
当你的Redis是执行 flushall shotdown 是迅速生成dump.rdb（有可能是空的rdb）。
一般是将备份数据放在其他的服务器上，防止数据丢失。当主服务器发生意外断点时会迅速的生成dump.rdb
恢复时如果本地的dump.rdb内没有数据。就使用其他机器上的备份恢复。恢复方法：删除没有数据的dump.rdb文件。
将备份复制到相应的路径，在重新启动Redis这是一般会有数据。
save 命令可以迅速备份。commit也会迅速备份。
snpashot
配置位置就是redis.conf文件中的快照配置 ：SNAPSHOTTING
如何触发RDB快照：
配置文件中默认的快照配置：冷拷贝后重新使用，可以 cp dump.rdb dump_new.rdb 拷贝到另一台的服务器上dump_new.rdb
恢复时使用新文件 dump_new.rdb恢复。
命令 save或者 bgsave，都可以迅速的备份生成dump.rdb
save： save时只管保存，其他不管，全部阻塞。
bgsave: Redis会在后台异步进行快照操作，但里面是空的没有意义
如何恢复：
经备份文件（dump.rdb）移动到Redis安装目录并启动服务即可。命令：config get dir 获取目录
RDB advantages (RDB 优势)
优势1：适合大规模的数据恢复
优势2：对数据完成性和一致性要求不高
劣势1：在一个定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照的所有修改
劣势2：Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
如何停止
动态所有停止RDB保存规则的方法：redis-cli config set save " "
总结
1.RDB是一个非常紧凑的文件
2.RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，所以RBD持久化方式可以最大化Redis的性能。
3.与AOF相比，在恢复大的数据集的时候ＲＤＢ方式会更快一些。
————————————————————————————————————
4.数据丢失风险大
5.RDB需要经常fork子进程保存数据集在硬盘上，当数据集比较大的时候，fork的过程是非常耗时的。可能会导致Redis在一些毫秒级不能响应客户端请求。
补充
dump.rdb默认生成路径是安装目录下，比如 我在 myredis 文件夹下启动redis服务 那么dump.rdb文件就在myredis文件下。
//有时在恢复dump.rdb文件会出现丢包现象，出现乱码，使用下面这个命令修复
redis-check-aof --fix dump.rdb