> 由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁 盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化。 ### **一、RDB持久化** RDB持久化是在指定的时间间隔内把当前进程数据生成快照保存到硬盘的过程，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。触发RDB持久化过程分为手动触发和自动触发。 **1、工作流程：** 1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。 2）父进程执行fork操作创建子进程，fork操作过程中父进程被阻塞。 3）父进程fork完成后，bgsave命令返回“\* Background saving started by pid xxx”信息，并不再阻塞父进程，可以继续响应其他命令。 4）父进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。根据lastsave命令可以获取最近一次生成RDB的时间，对应info Persistence中的rdb\_last\_save\_time。 5）进程发送信号给父进程表示完胜，父进程更新统计信息。  **2、触发机制：** 1）手动触发       包括save和bgsave命令。因为save会阻塞当前Redis节点，所以，Redis内部所有涉及RDB持久化的的操作都通过bgsave方式，save方式已废弃。 2）自动触发     1> 使用save的相关配置。     2> 从节点执行全量复制操作。     3> 执行debug reload命令。     4> 执行shutdown命令时，如果没有开启AOF持久化功能则会自动执行bgsave。 **3、优缺点** 1）优点 * 相比于AOF机制，如果数据集很大，RDB的启动效率会更高 * 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 * RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景。 2）缺点 * 没办法做到实时持久化/秒级持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高 * 系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失 **4、常用配置** Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息： ~~~ save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。 save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。 save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。 ~~~