Redis rdb持久化机制讲解
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文件