1.通过save与bgsave命令手动触发
-
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，线上环境不建议使用。
-
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短（微秒级别）。
2.通过配置文件自动触发
redis的配置文件redis.windwos.conf中有一下默认内容：
900秒内，至少有一个key进行了修改，就进行持久化操作
save 900 1
300秒内，至少有10个key进行了修改，就进行持久化操作
save 300 10
60秒内，至少有1000个key进行了修改，就进行持久化操作
save 60 10000
流程说明：
1.父进程执行fork操作创建子进程
2.子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原来文件进行原子替换。
3.进程发送信号给父进程表示完成，父进程更新统计信息。
整个过程主进程不进行任何io操作，保证了性能，如果进行大规模数据恢复，RDB和AOP都可以进行数据恢复，RDB数据恢复完整性不敏感，RDB更加高效，缺点时最后一次持久化后的数据可能丢失，默认使用的就是RDB，一般情况不需要修改这个配置。
RDB文件处理：
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定，默认为一个dump.rdb文件(在生产环境中最好对dump.rdb文件进行备份)。可以通过执行config set dir {newDir}和config set dbfilename {newFileName}运行期动态执行，当下次运行时会保存到新目录。
如果redis加载的RDB文件损坏时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件并获得对应的错误报告。
RDB优点：
-
RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适合备份：父进程正常处理用户请求，fork分支一个子进程进行备份。
-
适合大规模的数据恢复，如果服务器宕机了，不要删除rdb文件，重启自然在目录下，自动会读取，并且数据恢复速度远大于AOF方式。
总结
大型分布式系统犹如一个生命，系统中各个服务犹如骨骼，其中的数据犹如血液，而Kafka犹如经络，串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享，把Kafka的实现脉络展示在读者面前，帮助读者更好地研读Kafka代码。
CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】
麻烦帮忙转发一下这篇文章+关注我