Reids持久化-RDB
2023-11-01 本文已影响0人
风雪_夜归人
简介
持久化--将数据（如内存中的对象）保存到可永久保存的存储设备中
持久化方式
1.RDB：在指定的时间间隔内对数据进行快照存储。现将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，是一次全量备份
2.AOF：以日志文件的形式记录服务器所处理的每一个数据更改指令，然后通过重放来恢复数据，是连续的增量备份。
RDB触发和恢复
- 根据save m n配置规则自动触发
- 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发bgsave
- 执行debug reload时
- 执行shutdown时，如果没有开启aof也会触发
- 恢复方式：将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
RDB在redis.con中的配置
- save + time + n 在time秒内写入n条，即可触发快照
- dbfilename dump.rdb 默认保存文件
- dir ./ 保存路径
- stop-writes-on-bgsave-erroe yes 如果持久化出错，主进程是否停止写入
- rdbcompression yes 是否压缩
- rdbchecksum yes 导入时是否检查
RDB-Fork原理
image.png
执行RDB时，服务器执行以下操作：
- redis调用系统函数fork() 创建以给子进程
- 子进程将数据集写入到一个临时RDB文件中
- 当子进程完成对临时RDB文件写入时，reids用新的临时RDB文件替换原来的RDB文件，并移除旧文件
执行fork时，操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据（如执行一个写命令），操作系统会将该数据复制一份以保证子进程的数据不受影响。新的RDB文件存储的是执行fork那一刻的内存数据
在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧文件替换成新的。任何时候RDB文件都是完整的
RDB性能分析
优点
- 通过rdb文件恢复数据比较快
- rdb文件非常紧凑，适合于数据备份
- 通过rdb进行的数据备份，由于使用子进程生成，所以对redis服务器性能影响较小
缺点
- 采用RDB的方式可能会造成某个时段内数据丢失，比如还没达到触发条件时服务器死机，那么这个时间段内的数据就会丢失
- 使用save命令会造成服务器阻塞，数据备份完成后才能继续进行使用
- 使用bgsave命令在fork子进程时，如果数据量过大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存
