NoSQL——Redis持久化

一、概要

       Redis支持持久化，它支持两种持久化策略：

      1.RDB  Redis DataBase 

        在指定的时间间隔内将内存中的数据集快照写入到磁盘内，也就是将Snapshot快照文件恢复时直接读取到内存中。

        说得详细一点就是，Redis会单独创建一个（fork）子进程来进行持久化，会先将数据写入到这个临时文件中，等持久化过程都结束之后，再用这个临时文件替换上次持久化好的文件。

        整个过程中，主进程是不进行任何IO操作，这就确保了极高的性能，如果需要进行大量的数据恢复，且对于数据恢复的完整性不是很敏感，那RDB方式要比AOF方式更加高效，RDB的缺点就是最后一次持久化的数据可能丢失。

        好比说，5分钟快照一次，5分钟快照一次，那么，突然在4分59秒正准备要备份快照时挂了，此时这段数据没有被快照到，这样就容易丢失最后一次数据变更内容。 那么如何解决呢？（AOF策略）

       话说回来，Redis在内存中写入的数据快照是什么？是一个RDB保存的dump.rdb文件。

       1）Fork：Fork的作用是复制一个与当前进程完全一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数值都保持一致，但是是一个全新的进程，并作为原进程的子进程，拿来拷贝备份。

       2）RDB配置位置

       在redis.conf中可以看到如下

        save <多少秒以内> <改变多少次>

        配置好后，会产生一个dump.rdb文件。

    

       3）触发RDB快照

       场景：现在有一些数据需要立刻进行备份，那么你就需要触发快照。

       命令：save 或者是 bgsave

       区别：save：只管保存，其他不管，全部阻塞

                  bgsave：redis会在后台异步进行快照处理，快照的同时还可以响应用户操作，可以通过lastsave命令获取最后一次成功执行快照的时间

       4）如何恢复

        将备份文件dump.rdb移动到redis安装目录即可

        CONFIG GET dir获取目录

       5）优势

        （1）适合大规模的数据备份

        （2）对数据完整性和一致性要求不高

       6）劣势

        （1）最后一次数据可能丢失

        （2）Fork的时候，内存中的数据被克隆一份，大致2倍的膨胀性需要考虑

       7）动态所有停止RDB保存规则的方法：redis-cli config set save ""

       8）总结

          

      2.AOF  Append Only File

      以日志的形式来记录每个写操作，将redis执行过的所有写指令（读指令不记录）记录下来，同时只允许追加文件但不能改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容从前到后执行一次，以完成数据的恢复。

      AOF保存的是appendonly.aof文件 

      * RDB和AOF可以共存，redis启动先加载appendonly.aof。

      1）配置位置

    2）AOF的启动、修复、恢复

    正常恢复：

           启动：在redis.conf中将appendonly改为yes

           将有数据的aof文件复制一份保存到对应目录（可以用config get dir查看）

           恢复：重启redis然后重新加载即可

    异常恢复：

            启动：在redis.conf中将appendonly改为yes

            备份被写坏的aof文件

            修复：Redis-check-aof   --fix进行修复

            恢复：重启redis然后重新加载即可

    3）重写机制

            由于日志文件会越写越大，那么不停的写写写，什么时候回重写？

            AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阀值时，redis就会启动AOF的文件内容压缩，只保留可以恢复数据的最小指令集合，可以使用命令bgrewriteaof。

            原理：AOF持续过大时，会fork出一条新进程来将文件重写（先写入临时文件最后在rename），遍历新进程的内存中的数据，每一条记录有一个set语句，重写aof文件的操作，并没有读取旧的aof文件而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件，这点和快照有点类似。

     4）触发机制

           redis会记录上次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

     5）优势

        （1）每修改同步   同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整

        （2）每秒同步  默认使用   异步操作，每秒记录，如果有一秒宕机，有数据丢失

        （3）不同步      从不使用

     6）劣势

        （1） 相同的数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

        （2）  aof运行效率要慢于rdb，每秒同步策略较好，不同步的效率和rdb相同

     7）总结