RDB简介
我们都知道Redis是纯内存的操作，数据首先被保存到内存中，但是内存中的数据是非持久化数据，即当服务器宕机，或者断电之后，内存中的数据就会丢失。所以数据只有保存到硬盘中才能持久化。Redis中默认的持久化方式是RDB的方式。
RDB指的是在指定的时间间隔内将内存中的数据集快照写入磁盘，即Snapshot快照，它恢复时是将快照文件直接读取到内存里。
备份是如何执行的
Redis会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对数据恢复的完整性不会非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork
Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数值和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会由exec系统调用，处于效率考虑，Linux中引入了"写时复制技术"。
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
只所以采用这种方式是为了防止服务器挂掉之后，保证数据的一致性，如果直接从内存中将数据同步到dump.rdb中，那么在同步的过程中如果服务器发生故障的话，那么dump.rdb中的数据就会失去一致性和完整性。而如果写入临时文件的，只有当数据同步完成之后才会将临时文件中的数据写入到dump.rdb中。
配置文件说明
1. stop-writes-on-bgsave-error
当Redis无法写入磁盘的话，直接关掉Redis的写操作，推荐yes。
2. rdbcompression
对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，Redis会采用LZF算法进行压缩，
如果你不想消耗CPU来进行压缩的话，可以设置关闭。推荐yes
3. rdbchecksum
检查完整性，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。推荐yes。
4. dbfilename
指定rdb数据库文件的名称，默认是 dump.rdb
dir
dir 用于指定dump.rdb文件的路径，默认的路径是启动redis服务器的路径，即与 redis-server 同级。
save
格式：save 秒钟 写操作次数
RDB 是整个内存的压缩过的snapshot，RDB的数据结构，可以配置复合的快照来触发条件，默认是1分钟内改1万次，或者5分钟内改100次，或者1个小时内改了1次
这里我为了测试方面改成了20秒内修改3次就会同步。
save：save时只管保存，其他不管，全部阻塞，手动保存。
bgsave: Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间。
操作演示
在操作之前dump.rdb文件的大小是92kb，当在redis中插入三个键之后，再次查看发现 dump.rdb的大小变成了115kb。
优势
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快
劣势
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
虽然Redis在fork时使用的了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down的话，就会丢失最后一次快照后的所有修改。
总结
本文详细介绍了持久化操作RDB的使用，总体来说RDB数据适合于对数据一致性和完整性要求不高的场景，适合大规模数据的恢复，Redis默认是开启RDB持久化的，它的持久化过程是是首先将内存中的数据克隆一份，然后，在替换掉原有的RDB数据库。
