上一节讲到redis为了保证高可用，使用了AOF机制来确保数据不丢失，宕机之后，如果想要恢复数据，只能顺序执行aof的日志。但是对于4G满的redis数据，逐条执行aof日志时间太长，有没有其他方式呢？redis又引入了另外一个方式：RDB
RDB：redis database
RDB其实就是redis内存数据的快照-snapshot。这个快照保存的是某一个时间节点，redis内容中所有的数据，生成RDB文件，我们把它保存在文件系统，然后在宕机之后可以读取到内存中，完成数据的快速恢复。
如何生成快照：
在redis中，bgsave命令，可以使用fork子线程的模式，在不阻塞主线程的情况下，生成快照。save命令则是使主线程生成快照，这样就意味着要暂停服务
快照的机制其实比较关注两点：
- 记录哪些信息：因为redis是内存存储系统，只保存了key-value，所以redis的数据要全量保存
- 什么时候拍摄快照：如果为了保证数据丢失的少，要频繁的生成快照，在fork的时候，主线程要暂时停顿一下，而且多个自线程可能会在快照生成过程中争用RDB文件，造成并发问题
- 会不会阻塞主线程：使用bgsave的命令会fork一个子线程，来共享主线程的redis数据存储，那么在生成快照的时候，主线程还是可以提供写服务的，这个时候如果在执行的写命令的时候，会使用Copy-on-write技术，复制一块key-value实体的副本，子线程还是会读取副本的数据，主线程修改原始数据
图片来源：极客时间-蒋德钧老师的redis课程，链接地址：https://time.geekbang.org/column/article/271839
那么就会面临和AOF一样的问题，可能会丢失上一次快照到宕机时间内的数据操作。为了避免这个问题，redis结合RDB和AOF量大功能。在快照生成之后，清空AOF日志，所有的写操作都记录到AOF日志文件。这样就可以保证数据的完整性。恢复数据的时候就可以拿最新的快照，再执行AOF里面的日志就可以恢复数据了