【Redis】RDB快照

1、背景

RDB（Redis Database）是redis默认的持久化方式，它通过创建内存数据的快照来实现持久化。RDB文件是个经过压缩的二进制文件，包含了redis在某个时间点的完整数据状态。

2、RDB触发机制

【1】自动触发

通过配置文件设置触发条件，每隔一段时间就会执行BGSAVE（可配置多个条件，满足一个就会触发）：

save 900 1 #900秒内至少有1个key被修改
save 300 10 #300秒内至少有10个key被修改
save 60 100 #60秒内至少有100个key被修改

【2】手动触发

同步保存（阻塞式，不推荐在生产环境使用，会导致redis阻塞直到RDB文件创建完成）

命令：SAVE

异步保存（后台保存，推荐使用方式，redis会fork子进程进行保存）

命令：BGSAVE

【3】其它触发场景

1、执行SHUTDOWN命令时
2、主从复制时，从库首次同步会触发主库执行BGSAVE
3、使用DEBUG RELOAD命令时

3、RDB文件生成过程

【1】BGSAVE工作流程

1、主进程收到BGSAVE命令
2、fork()创建子进程（使用写时复制技术）
3、子进程将内存数据写入临时RDB文件，完成后替换旧RDB文件
4、主进程继续处理客户端请求，记录子进程完成状态

【2】关键技术实现

<1>写时复制（Copy-On-Write）

1、子进程与父进程共享内存空间
2、只有被修改的内存页才会被复制

<2>文件处理

1、临时文件名：temp-[pid].rdb
2、原子替换：使用rename()系统调用保证原子性

<3>压缩处理

1、默认采用LZF压缩算法
2、可配置压缩阈值：
[root@xxx]# cat /xxx/redis.conf | grep > 'rdbc'
rdbcompression yes #是否压缩
rdbchecksum yes #是否包含校验和

4、RDB配置参数

参数	默认值	说明
dbfilename	dump.rdb	RDB文件名
dir	./	RDB文件存储目录
stop-writes-on-bgsave-error	yes	持久化失败时是否停止写入
rdbcompression	yes	是否压缩RDB文件
rdbchecksum	yes	是否写入校验和
rdb-del-sync-files	no	是否删除无用的RDB文件

5、RDB优缺点

优点	缺点
高性能：生成快照时使用子进程，主进程几乎不受影响	数据丢失风险：可能丢失最后一次快照后的所有数据（取决于配置的保存间隔）
快速恢复：二进制压缩格式加载速度远快于AOF	fork阻塞风险：大数据集时fork操作可能耗时
紧凑存储：二进制压缩格式，文件提交通常比AOF小很多	实时性差：只能保存某个时间点的数据状态，无法做到秒级持久化
适合备份：完整的单文件快照，便于迁移和灾难恢复	兼容性问题：不同redis版本的RDB格式可能有差异
最大化redis性能：持久化过程对正常服务影响最小	不记录操作历史：无法追溯数据变化过程
内存效率高：使用写时复制技术，内存开销小	不可控的持久化：自动触发依赖于配置的save规则

6、RDB与AOF对比

特性	RDB	AOF
持久化方式	快照	日志
数据安全性	可能丢失数据	可配置不同的安全级别
恢复速度	快	慢
文件大小	小	大
性能影响	保存时影响较大	持续写入影响较小
适用场景	灾难恢复、备份	高数据安全要求