Redis RDB持久化

1. RDB持久化本质为文件存储，将Redis管理的内存数据压缩生成.rb二进制文件;对应RDB文件路径由redis.conf的配置中的dir字段配置，默认的位置是./，表示当前位置，哪里启动Redis，就会在哪里生成持久化文件。
2. 在Redis服务启动时，检测到RDB文件则会自动载入文件，会占用一定服务启动时间。
3. SAVE为主线程执行，会阻塞Redis服务；BGSAVE在新建子线程执行，不会阻塞Redis服务，但是执行结束前会忽略掉SAVE、BGSAVE、BGREWRITEAOF 三个命令（避免同时修改同一资源，避免同时进行大量读写操作）。
4. 自动保存：SAVE/BGSAVE 时间间隔 数据变化数量
   例如：
   save 300 10
   当满足服务器在 300 秒之内，对数据库进行了至少 10次修改时出发save操作
   Redis的服务默认每隔 100 毫秒就会执行一次serverCron函数，用于对正在运行的服务器进行维护，它的其中一项工作就是检查 save 选项所设置的保存条件是否已经满足，如果满足的话，就执行对应命令；
   保存条件的判断依赖一下两个字段：
   服务中的dirty计数器会记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态进行了多少次修改（包括写入、删除、更新等操作）；
   服务中的lastsave 属性是一个 UNIX 时间戳，记录了服务器上一次成功执行 SAVE 命令或者 BGSAVE 命令的时间；

• 优势

1. RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，可以使用子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

• 劣势

1. RDB方式数据没办法做到实时持久化/秒级持久化。因为BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
2. RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
3. 在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

2020-05-08