目录
1、简介：
在指定的时间间隔内将内存的数据快照写入磁盘，也就是行话讲的快照，他恢复时是将快照的文件的直接读到内存里。
2、如何执行?
Redis会单独创建一个子进程（fork）来进行持久化，首先他会将数据写入到一个临时文件汇中，等待持久化的过程都结束了，在用这个历史文件代替上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就保证了极高的性能，如果需要进行大规模数据的回复，且对于数据的恢复，且对于数据的恢复的完整性不是很敏感，那RDB的方式比AOF方式更加的高效。缺点就是最后的一次持久化可能会丢失
3、Fork
Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
在Linux 程序中, fork(会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑, Linux中引入了“写时复制技术”。
一般情况父进程和子进程会共用同一 段物理内存，只有进程空间的各段的内容要
发生变化时,才会将父进程的内容复制一份给子进程。
?
复制的进程信息不会立即放到持久化文件中，而是有一个临时区域。先将数据放到临时区域，等待处同步完成再放到持久化文件中。
简单理解
?
为什么不直接放到持久化文件中呢？
假如说我程序正在执行但是我突然程序非正常挂掉了，而此时复制的不完整数据也被储存在了持久化文件中，这就造成持久化文件的不完整。这样就保证了数据的完整性，一致性和安全性。这就是写时复制技术。
4、redis实现RDB
首先在redis启动目录的bin下，可以看到dump.rdb文件
?然后持久化的相关配置是在redis.conf内部，，其中几个重要的部分
save
?save 900? ?1 是指在900秒内至少有1个key变化，就进行持久化操作。
?save 300? ?10是指在300秒内至少有10个key变化，就进行持久化操作
值得一提的是，save比较任性，他只管保存，其余啥都不管，全部阻塞。手动保存，不建议。
而bgsave：会在后台进行快照操作，快照同时还可以响应客户端请求。
dbfilename
?dir
?stop-writes-on- bgsave-error yes 推荐yes
rdbcompression
?rdbchecksum 检查完整性，在储存快照以后，进行数据校验，虽然这样做会消耗10%的性能但是，开启后会保证数据的正确性，为了提升效率也可以关闭
5、优点
适合大规模的数据恢复。
对数据完整性和一致性要求不高更适合使用。
节省磁盘空间。
恢复速度快。
6、缺点
Fork的时候，内存中的数据被克隆了一份，也就是内存使用应该是两倍。
即使redis在fork时使用了写拷贝技术，但是如果数据量庞大时还是消耗性能
周期性备份，若果某一时刻redis突然挂掉，会丢失最后一次数据。