1.redis持久化的方式有两种：RDB 和 AOF

RDB：类似于linux的快照，在某个时间点备份 临时文件 。

是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

  优点：1.每隔一段时间备份，全量备份

             2.灾备简单，可以远程传输

             3.子进程进行备份时，主线程不会有任何io操作（不会有写入修改或删除），保证备份数据的完整性

            4.相对于AOF来说，当有更大文件的时候，就可以快速重启恢复

缺点：1.发生故障时，有可能会丢失最后一次的备份数据

           2.子进程所占用的内存会和父进程一样，造成CPU负担

          3.由于定时全量备份是重量级的操作，所以对于实时备份，就无法处理

触发机制：

1.手动触发：

                  手动触发也分别对应 save 和bgsave 命令：

             1.1  save命令：

                                    阻塞当前redis服务器，直到  RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。

            1.2 bgsave命令:

                                   Redis进程执行fork操作 创建子进程，RDB持久化过程由子进程负责，完成后，自动结束。阻塞只发生在fork阶段，一般时间会很短。【bgsave命令是针对save阻塞问题做的优化，因此 Redis内部所有涉及 RDB 的操作都采用 bgsave的方式】

2.自动触发

            自动触发模式：

找到： SNAPSHOTTING(快照)

接着往下找;

dir：就是定义的RDB所保存的位置，

保存在磁盘的名称 就是 dump.rdb

这就是 dump.rdb

回到 redis.conf：

保存 更改时间  发生的更改次数

如果发生了 一次更改，则在15分钟后进行备份（保存快照），

如果至少发生了10次更改，则在5分钟后进行备份（保存快照）

如果在保存的过程中发生错误，yes就是停止写的操作。

no继续保存（会造成数据不一致）

stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩，会消耗CPU性能，但是现在企业的云盘性能一般都有剩余，所以不是大问题。

流程说明：

        bgsave是主流的触发 RDB持久化方式，下面是他的运作流程：

1.执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如 RDB/AOF子进程，如果存在 ，bgsave命令直接返回。

2.父进程执行fork操作创建子进程，fork操作过程中，父进程会阻塞，【fork操作的耗时，单位为微秒】

3.父进程完成fork操作后，bgsave 命令返回 “Background saving started” 信息并且 不在阻塞父进程，可以继续响应其他命令。

4.子进程创建 RDB文件，根据父进程内存生产临时快照文件，完成对原有文件进行原子替换。

5.进程发送信号给父进程表示完成，父进程更新统计信息