Redis的数据持久化方式有 RDB 和 AOF 两种,这篇文章将会讲解 RDB
RDB是什么
RDB方式是在指定的时间间隔内将内存中的数据集写入磁盘。
RDB怎么进行持久化
如果使用RDB方式进行持久化,Redis会单独创建(fork)一个子进程来进行持久化,它会先将数据写入一个临时文件中,待持久化过程结束后,再用本次创建的临时文件替换上次创建的临时文件。
注意:在整个过程中,主进程不进行任何 IO 操作,这样一来确保了极高的性能
可以在redis.conf中修改RDB的时间间隔,默认设置了三种触发RDB快照生成的情况
- 900秒(15分钟)内至少 1 个key被修改
- 300秒(5分钟)内至少 10 个key被修改
- 60秒内至少 10000 个key被修改
满足以下任一条件都会触发RDB快照生成:
- 配置文件的时间间隔规则
- 用户使用save和bgsave命令生成快照(bgsave是后台异步备份,备份的同时可以处理客户端操作)
- 主从复制时,主库触发RDB快照生成
- 客户端执行FLUSHALL或SHUTDOWN命令时(注意这里是一个危险点)
触发了RDB后可以在当前目录下找到dump.rdb文件,这就是内存快照文件了(文件位置和文件名都是可以通过配置文件修改的)
RDB的优势
- RDB是一个非常紧凑的单一文件,它可以表示某一时间点你的数据集情况,非常适合用于版本备份。RDB通过内置的LZF压缩算法使得文件紧凑,你也可以关闭这一功能换取更多的CPU资源
- RDB很擅长灾后重建,因为它是一个紧凑的单一文件,你可以将它传送到任何一个服务器中做备份
- RDB性能很好,它仅需要主进程创建一个子进程进行备份,主进程不参与磁盘的IO操作
- 相较于AOF,RDB的数据恢复速度更快
RDB的劣势
- 如果你希望尽可能减少数据的损失,那么RDB可能表现不够优秀,因为如果在未达到快照时间时发生了断电,宕机等错误,那么这一时间间隔内的数据将会全部丢失。当然,你也可以通过修改更短的触发快照的时间间隔来减少损失,但这样又会导致频繁的备份降低性能
- RDB通过创建(fork)子进程对内存数据进行备份,而fork操作会消耗系统资源,如果数据量庞大的话,fork的过程可能会导致redis客户端出现延迟