版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
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客户端出现延迟