redis持久化分为两种，分别为：快照(snapshotting)、只追加文件(append-only file)

     为什么要将内存中的数据持久化？

   重用数据、防止系统故障而将数据备份到一个远程位置

   配置信息如下：

      快照持久化：通过创建快照来获取存储在内存里面的数据在某个时间点上的副本

  

    创建快照的方法：

        1. BGSAVE命令来创建一个快照，redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求

        2.SAVE命令来创建一个快照，redis接到SAVE命令后，在创建快照完毕之前将不再响应任何命令；通常在没有足够内存去执行BGSAVE命令情况下或者等待持久化操作执行完毕也无所谓的情况下，才会使用

        3.配置了save配置选项,比如save 60 1000，'60秒之内有1000次写入'，当满足该条件时，redis就会自动触发bgsave命令；用户可以设置多个save配置选项，当任意一个设置的条件被满足时，redis就会触发一次bgsave命令

        4.当redis通过shutdown命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个save命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在save命令执行完毕后关闭服务器

        5.主从情况下，主服务器发送sync命令来开始一次复制操作的时候，主服务器目前没有在执行bgsave操作，或者主服务器不是刚刚执行完bgsave操作，那么主服务器就会执行bgsave命令

     使用快照服持久化，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据；快照持久化只适用于即使丢失一部分数据也不会造成问题的应用程序

     场景：

         

           

            

       3.大数据

       bgsave：redis创建子进程并将数据保存在硬盘里，随着redis占用内存越来越多，在创建子进程时耗费的时间也会越来越多，如果内存占用量达到十几G，那么执行bgsave可能导致系统长时间的停顿，导致redis性能降低至无法使用的程度

为了防止redis因为创建子进程出现停顿，我们可以选择关闭自动保存，使用save来持久化；但是save会一直阻塞redis直到快照生成完毕，并且没有子进程在争抢资源，所以save比bgsave创建快照的速度快一些

    AOF: 将被执行的写命令写到AOF文件的末尾，记录数据发生的变化；redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集
     appendfsync配置文件-- AOF文件同步频率的影响

always:每个redis写命令都要同步写入硬盘，这样设置会严重降低redis的速度；当系统出现崩溃的时候，数据丢失减到最少，这种同步策略需要对硬盘进行大量的写入，redis处理命令的速度会受到硬盘性能的限制

everysex:每秒执行一次同步，显式地将多个写命令同步到硬盘；这种设置和不设置持久化时的性能相差无几，而且每秒同步一次AOF文件，即使系统出现崩溃，用户最多只会丢失一秒之内产生的数据；当硬盘忙于执行写入操作的时候，redis还会放慢速度以便适应硬盘的最大写入速度

no:让操作系统来决定应该何时进行同步；一般情况下不会对redis性能带来影响，但系统崩溃将导致使用这种选项的redis服务器丢失不定数据量的数据；还有，如果用户的硬盘写入操作的速度不够快的话，那么当缓冲区被等待写入硬盘的数据填满时，redis的写入操作会被阻塞，并导致redis处理命令请求速度变慢，所以不推荐使用no  

重新/压缩AOF文件

问题：AOF持久化既可以将丢失数据的时间窗口降低至1秒，又可以在极短的时间内完成定期的持久化操作，有什么理由不使用AOF持久化呢？

因为redis会不断的将执行的写命令记录到AOF文件里面，随着redis不断运行，AOF文件的体积也会不断增长，甚至在极短的情况下，体积不断增大的AOF文件甚至可能会用完硬盘的所有可用空间；

redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，如果AOF文件体积非常大，那么还原操作执行的时间就可能会非常长

      解决AOF体积过大不断增大的问题
         redis发送BGREWRITEAOF命令，这个命令会移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能更小

BGREWRITEAOF工作原理：redis会创建一个子进程，然后由子进程，然后由子进程负责对AOF文件进行重写。AOF文件重写也用到了子进程，快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF中页同样存在这样的问题；更糟的是，不做控制的话，AOF文件的体积可能会比快照文件的体积大好几倍，在进行AOF重写并删除旧AOF文件的时候，删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统挂起数秒

AOF持久化设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size选项 来自动执行BGREWRITEAOF

例如：auto-aof-rewrite-percentage=100 和auto-aof-rewrite-min-size=64mb  启用AOF持久化，当AOF文件的体积大于64MB,并且AOF文件的体积比上一次重写之后的体积大了至少1倍的时候，redis将执行 BGREWRITEAOF命令；如果AOF操作频繁的话，用户可以考虑将auto-aof-rewrite-percentage设置为100以上，这种做法可以让Redis在AOF文件体积变的更大之后才执行重写操作，不过也会让redis在启动时还原数据集所需的时间变得更长；

  redis持久化分为两种，分别为：快照(snapshotting)、只追加文件(append-only file)

     为什么要将内存中的数据持久化？

   重用数据、防止系统故障而将数据备份到一个远程位置

   配置信息如下：

      快照持久化：通过创建快照来获取存储在内存里面的数据在某个时间点上的副本

  

    创建快照的方法：

        1. BGSAVE命令来创建一个快照，redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求

        2.SAVE命令来创建一个快照，redis接到SAVE命令后，在创建快照完毕之前将不再响应任何命令；通常在没有足够内存去执行BGSAVE命令情况下或者等待持久化操作执行完毕也无所谓的情况下，才会使用

        3.配置了save配置选项,比如save 60 1000，'60秒之内有1000次写入'，当满足该条件时，redis就会自动触发bgsave命令；用户可以设置多个save配置选项，当任意一个设置的条件被满足时，redis就会触发一次bgsave命令

        4.当redis通过shutdown命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个save命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在save命令执行完毕后关闭服务器

        5.主从情况下，主服务器发送sync命令来开始一次复制操作的时候，主服务器目前没有在执行bgsave操作，或者主服务器不是刚刚执行完bgsave操作，那么主服务器就会执行bgsave命令

     使用快照服持久化，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据；快照持久化只适用于即使丢失一部分数据也不会造成问题的应用程序

     场景：

         

           

            

       3.大数据

       bgsave：redis创建子进程并将数据保存在硬盘里，随着redis占用内存越来越多，在创建子进程时耗费的时间也会越来越多，如果内存占用量达到十几G，那么执行bgsave可能导致系统长时间的停顿，导致redis性能降低至无法使用的程度

为了防止redis因为创建子进程出现停顿，我们可以选择关闭自动保存，使用save来持久化；但是save会一直阻塞redis直到快照生成完毕，并且没有子进程在争抢资源，所以save比bgsave创建快照的速度快一些

    AOF: 将被执行的写命令写到AOF文件的末尾，记录数据发生的变化；redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集
     appendfsync配置文件-- AOF文件同步频率的影响

always:每个redis写命令都要同步写入硬盘，这样设置会严重降低redis的速度；当系统出现崩溃的时候，数据丢失减到最少，这种同步策略需要对硬盘进行大量的写入，redis处理命令的速度会受到硬盘性能的限制

everysex:每秒执行一次同步，显式地将多个写命令同步到硬盘；这种设置和不设置持久化时的性能相差无几，而且每秒同步一次AOF文件，即使系统出现崩溃，用户最多只会丢失一秒之内产生的数据；当硬盘忙于执行写入操作的时候，redis还会放慢速度以便适应硬盘的最大写入速度

no:让操作系统来决定应该何时进行同步；一般情况下不会对redis性能带来影响，但系统崩溃将导致使用这种选项的redis服务器丢失不定数据量的数据；还有，如果用户的硬盘写入操作的速度不够快的话，那么当缓冲区被等待写入硬盘的数据填满时，redis的写入操作会被阻塞，并导致redis处理命令请求速度变慢，所以不推荐使用no  

重新/压缩AOF文件

问题：AOF持久化既可以将丢失数据的时间窗口降低至1秒，又可以在极短的时间内完成定期的持久化操作，有什么理由不使用AOF持久化呢？

因为redis会不断的将执行的写命令记录到AOF文件里面，随着redis不断运行，AOF文件的体积也会不断增长，甚至在极短的情况下，体积不断增大的AOF文件甚至可能会用完硬盘的所有可用空间；

redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，如果AOF文件体积非常大，那么还原操作执行的时间就可能会非常长

      解决AOF体积过大不断增大的问题
         redis发送BGREWRITEAOF命令，这个命令会移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能更小

BGREWRITEAOF工作原理：redis会创建一个子进程，然后由子进程，然后由子进程负责对AOF文件进行重写。AOF文件重写也用到了子进程，快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF中页同样存在这样的问题；更糟的是，不做控制的话，AOF文件的体积可能会比快照文件的体积大好几倍，在进行AOF重写并删除旧AOF文件的时候，删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统挂起数秒

AOF持久化设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size选项 来自动执行BGREWRITEAOF

例如：auto-aof-rewrite-percentage=100 和auto-aof-rewrite-min-size=64mb  启用AOF持久化，当AOF文件的体积大于64MB,并且AOF文件的体积比上一次重写之后的体积大了至少1倍的时候，redis将执行 BGREWRITEAOF命令；如果AOF操作频繁的话，用户可以考虑将auto-aof-rewrite-percentage设置为100以上，这种做法可以让Redis在AOF文件体积变的更大之后才执行重写操作，不过也会让redis在启动时还原数据集所需的时间变得更长；