本文主要是介绍Redis持久化策略之RDB快照，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

目录

介绍

触发机制：

bgsave命令生成快照的过程如下：

RDB的缺陷：

1.可能会丢失数据

（1）快照周期引发的数据丢失风险形象图：

（2）配置策略引发的数据丢失：

2.占用系统资源、阻滞系统服务

介绍

快照可以让redis在内存中的数据持久化到快照文件，这样下次启动redis时就能从文件中直接加载数据到内存；也为redis故障宕机做了一个保障。

RDB即Redis DataBase ，默认的持久化方式。按照一定的周期将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。

触发机制：

（1）用户发送bgsave命令(fork一个子进程,子进程生成快照,父进程继续接收用户命令)

（2）用户发送save命令(发送save命令后,到快照创建完成之前系统不会再接收新的命令,即save命令会阻塞后面的命令,而bgsave不会)

（3）达到配置文件中的save参数定义的周期（也是用bgsave模式）

（4）执行 flushall 命令

（5）退出redis时（然后redis先启用save保存快照，之后再关闭服务器）

（6）主从架构,从服务器向主服务器发送sync命令来执行复制操作时,只要主服务器当时没有进行bgsave操作,那么主服务器就会执行bgsave操作

bgsave命令生成快照的过程如下：

（1）Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；

（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；

（3）当子进程写入完所有数据后会用该临时文件替换旧的 RDB 文件，至此一次快照操作完成。

RDB的缺陷：

1.可能会丢失数据

通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据（因为临时文件写入完成才会替换旧快照文件）。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。例如，使用Redis存储缓存数据时，丢失最近几秒的数据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

（1）快照周期引发的数据丢失风险形象图：

（2）配置策略引发的数据丢失：

配置文件中save 60 1000,如果我在60秒内只更新了900条数据,然后系统崩溃了,那么这900条数据就没了

2.占用系统资源、阻滞系统服务

大数据量的时候，持久化操作会长时间阻滞系统服务，即使是bgsave模式也有可能占用较多的系统资源而影响服务性能

这篇关于Redis持久化策略之RDB快照的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！