Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。
- save：在主线程中执行，会导致阻塞；
- bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是Redis RDB 文件生成的默认配置。
RDB持久化机制，对redis中的数据执行周期性的持久化。每间隔一段时间,生产redis中的数据一份完整的快照。
快照是一次全量备份，是内存数据的二进制序列化形式，在存储上非常紧凑。
快照原理
我们知道 Redis 是单线程程序，这个线程要同时负责多个客户端套接字的并发读写操作和内存数据结构的逻辑读写。
在服务线上请求的同时，Redis 还需要进行内存快照，内存快照要求 Redis 必须进行文件 IO 操作，可文件 IO 操作是不能使用多路复用 API。
这意味着单线程同时在服务线上的请求还要进行文件 IO 操作，文件 IO 操作会严重拖垮服务器请求的性能。
还有个重要的问题是为了不阻塞线上的业务，就需要边持久化边响应客户端请求。
持久化的同时，内存数据结构还在改变，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它给删掉了，还没持久化完呢，怎么搞？
Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作，
JUC中的CopyOnWriteArrayList也是类似的思想。
bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。
此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
RDB持久化机制的优点
- 适合做冷备
RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。
RDB做冷备，生成多个文件，每个文件都代表了某一个时刻的完整的数据快照。AOF也可以做冷备，只有一个文件，但是你可以，每隔一定时间，去copy一份这个文件出来
RDB做冷备，优势在哪儿呢？由redis去控制固定时长生成快照文件的事情，比较方便; AOF，还需要自己写一些脚本去做这个事情，各种定时
RDB数据做冷备，在最坏的情况下，提供数据恢复的时候，速度比AOF快
- RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能
因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。RDB每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中。AOF，每次redis写操作都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的,速度肯定比RDB略慢一些
- 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的。
RDB，就是一份二进制数据文件，恢复的时候，直接加载到内存中即可。
RDB持久化机制的缺点
- 不适合做第一优先的恢复方案
如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是rdb最大的缺点，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多
- RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒
一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的
配置RDB持久化机制
edis.conf文件，也就是
/etc/redis/6379.conf，去配置持久化save 60 1000每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成
save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生
了变更，如果有，就生成一个新的dump.rdb文件
基于RDB持久化机制的数据恢复实验
（1）在redis中保存几条数据，立即停掉redis进程，然后重启redis，看看刚才插入的数据还在不在数据还在，为什么？
带出来一个知识点，通过redis-cli SHUTDOWN这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照
/var/redis/6379/dump.rdb（2）在redis中再保存几条新的数据，用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景
这次就发现，redis进程异常被杀掉，数据没有进dump文件，几条最新的数据就丢失了
（2）手动设置一个save检查点，save 5 1
（3）写入几条数据，等待5秒钟，会发现自动进行了一次dump rdb快照，在dump.rdb中发现了数据
（4）异常停掉redis进程，再重新启动redis，看刚才插入的数据还在
rdb的手动配置检查点，以及rdb快照的生成，包括数据的丢失和恢复，全都演示过了