首先先来谈一谈对持久化的理解 持久化(Persistence) 在Redis中的工作原理就是将你存储在缓存中的数据集异步的保存在你的磁盘中实现持久存储 当电脑或者服务器发生宕机时 我们的内存会被清空 但是存储在磁盘中的数据不会丢失 当我们再次打开Redis时 磁盘中的数据集就会再次同步到我们的Redis中 也就是从磁盘中再次回到内存中。

        一、Redis持久化的实现方式

                实现方式主要分为了：快照持久化(RDB)、写日志持久化(AOF)

       1、快照方式持久化

                快照方式持久化就是在某时刻把所有数据进行完整备份。

                例：Mysql的Dump方式、Redis的RDB方式。

        2、写日志的方式持久化AOF

              写日志方式持久化就是把用户执行的所有写指令（增删改）备份到文件中，还原数据时只需要把备份的所有指令重新执行一遍即可。

例：Mysql的Binlog、Redis的AOF、Hbase的HLog。

        

        二、RDB了解

        前面说到了Redis持久化的 实现方式主要分为了：快照持久化(RDB)、写日志持久化(AOF)

其中快照持久化方式也就是RDB 

         RDB的持久化方式主要就是在指定的时间间隔对你的数据集进行一个快照存储 在默认的情况下 Redis快照完成后会把数据集保存在一个名为 dump.rdb的文件中 这个文件是一个二进制格式的文件 在Redis运行时 RDB会将内存中的数据集存储到磁盘中 在Redis重启时 可以通过载入RDB文件到RDB程序进行一个数据的同步恢复

        工作方式

当Redis需要保存dump.rdb文件时，服务器执行以下操作：

1. Redis调用forks()，同时拥有父进程和子进程。
2. 子进程将数据集写入到临时的RDB文件中。
3. 当子进程完成对RDB文件的写入时，Redis会用新的RDB文件替换旧的RDB文件，并删除旧的RDB文件。

        这种工作方式使得Redis可以从写时复制（copy-on-write）机制中获益。

        RDB的触发方式

        RDB主要有三种触发方式：save命令、bgsave命令、save配置

        简单讲一下这三种触发方式 原理有感兴趣的可以去看源码

        1、save命令执行一个同步操作，以RDB文件的方式保存所有数据的快照。

              save命令会占用内存 数据集较小时没有影响 但是如果数据集较大 或者消费者较多时 很容易发生redis阻塞 因为save是一个同步时操作 会影响后面的进程

        2、bgsave命令执行一个异步操作，以RDB文件的方式保存所有数据的快照。

              见闻知意 bgsave可以看做 background save 也就是后台存储的意思 在执行bgsave时 Redis会使用Linux系统中的 fokc() 去生成一个子线程来处理数据的快照 

        可以看下图 ：在运行中如果需要大数据量的一个快照 bgsave会生成一个子线程去处理快照操作不会去影响图片中4和5的进程 

        如果使用save的话 就会在2和4之间进行同步快照 快照结束后才会执行4操作 大大降低了用户体验 所以bgsave还是全方面碾压save的！ 

        3、save配置

          

      除了手动执行 save 和 bgsave 命令实现RDB持久化以外，Redis还提供了自动生成RDB的方式。

        你可以通过配置文件对 Redis 进行设置，让它在 N 秒内数据集至少有 M 个改动这一条件被满足时，自动进行数据集保存操作。

        比如说，以下设置会让 Redis 在满足60 秒内有至少有1000个键被改动这一条件时， 自动进行数据集保存操作:。

        这个也就是单纯的字面意思 类似于定时判断任务 只要 达到我设置的时间 或者数据达到了我设置的一个大小 就会进行快照保存操作

下图可以看一下save和bgsave的区别

 

 RDB的优缺点

1. RDB优点
   1. RDB是一个非常紧凑的文件，它保存了某个时间点得数据集，非常适用于数据集的备份，比如你可以在每个小时报保存一下过去24小时内的数据，同时每天保存过去30天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
   2. RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复。
   3. RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
   4. RDB与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

1. RDB缺点
   1. 耗时、耗性能。RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续1秒，AOF也需要fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。
   2. 不可控、丢失数据。如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。