Redis持久化另一种方式：RDB快照
RDB
RDB快照，将某一时刻的内存数据生成快照（二进制的形式）写入磁盘。
AOF是记录操作，RDB是某一时刻的数据快照。所以，在数据恢复时，只需直接把RDB文件读入内存，完成快速恢复
触发机制
手动触发
save
- 通过发送save命令请求持久化时，会阻塞Redis server 处理其他请求，直到数据同步完成
bgsave
- 发送bgsave命令请求持久化时，redis主进程会fork一个子进程，异步将数据保存到rdb文件中，同步完数据后，对原有文件进行替换，然后通知主进程同步完成
自动触发
配置中集中配置 save m n 其表示，m秒内数据集存在n次修改时，系统自动触发bgsave操作
RDB优缺点
优点：
- RDB文件小，适合定时备份，用于灾难恢复
- RDB文件直接存储的是内存数据，AOF文件中存储的是一条命令，所以Redis加载RDB文件的速度比AOF文件快
缺点：
- RDB持久化无法做到实时/秒级持久化。实时持久化需全量刷内存到磁盘，成本高
- RDB文件是二进制文件，如果Redis升级不同版本有多个RDB文件的版本，不支持跨版本兼容
问题思考
1、RDB做快照会阻塞线程吗？
首先，Redis是单线程进行处理数据的。学习RDB的触发机制有手动和自动2种方式，在手动出发中通过两种命令save和bgsave。
- save命令方式会阻塞主线程直到同步完成，会阻塞主线程
- bgsave方式是主线程通过fork一个子线程进行同步，不会阻塞主线程（默认配置）
2、RDB做快照时数据能修改吗？
假如想象在执行快照的过程中，数据被修改或不能被修改的场景
- 若可以执行写操作，意味着Redis还能正常处理写操作，就可能发生正在执行快照的数据是已经被修改了的情况
- 若不可以写操作，意味着所有的Redis的所有写操作都得等到快照执行完成后才能执行，就出现阻塞主线程的问题
如何解决？
使用bgsave可以解决它
- 主线程执行读操作，则主线程和bgsave子进程互不影响
- 主线程执行写操作，则被修改的数据会复制一份副本，然后bgsave子进程会把该副本数据写入RDB文件，此过程，主线程仍可以修改原来数据
