Redis rdb持久化机制讲解
- 1.触发条件
- bgsave的执行流程
- SAVE M N 的实现原理
- 启动时加载
1.触发条件
手动触发 可以采用bgsave 和 save方法 都可以产生rdb文件,save方法会阻塞redis 服务器进程，直到RDB文件生成为止，而bgsave方法会fork出来一个子线程，并不会去阻塞主线程
自动触发，可以在redis.conf 中去配置 save m n ，m是指的秒数，n指的是在m的期间的内，key指的变化到了多少的量，才会去进行一个rdb文件的生成。
在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
执行shutdown命令时，自动执行rdb持久化
bgsave的执行流程
图片中的5个步骤所进行的操作如下：
- Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（后面会详细介绍该命令）的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
- 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
- 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
- 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
- 子进程发送信号给父进程表示完成，父进程更新统计信息
当执行到第四步的时候 如果redis宕机，那么是会存在丢失数据的情况的。
我去修改了redis.conf的配置文件 将其改成了save “” 意为自动开启rdb保存，注意 shutdown 命令还是会进行一个rdb文件保存的。如果需要测试的话 请直接杀掉进程，如图下所示，
当我再次重启，我之前的数据就丢失了。
接下来 我将配置项修改为save 60 1 即为60s内进行一次key值得修改 就会保存rdb文件。这里可以看到我保存了四个值
它进行了保存
SAVE M N 的实现原理
Redis的save m n，是通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。
serverCron是Redis服务器的周期性操作函数，默认每隔100ms执行一次；该函数对服务器的状态进行维护，其中一项工作就是检查 save m n 配置的条件是否满足，如果满足就执行bgsave。
dirty计数器是Redis服务器维持的一个状态，记录了上一次执行bgsave/save命令后，服务器状态进行了多少次修改(包括增删改)；而当save/bgsave执行完成后，会将dirty重新置为0。
例如，如果Redis执行了set mykey helloworld，则dirty值会+1；如果执行了sadd myset v1 v2 v3，则dirty值会+3；注意dirty记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。
astsave时间戳也是Redis服务器维持的一个状态，记录的是上一次成功执行save/bgsave的时间。
save m n的原理如下：每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件满足，就进行bgsave。对于每一个save m n条件，只有下面两条同时满足时才算满足：
（1）当前时间-lastsave > m
（2）dirty >= n
启动时加载
当没有开启AOF持久化配置时，redis启动时会去载入RDB文件进行一个启动处理，如果开启了AOF持久化配置，则先读取appendonly.aof文件
