浅谈Redis持久化

        大家都知道Redis增删改查的操作比MYSQL增删改查操作要快。原因是MYSQL的增删改操作是在硬盘上直接操作，而Redis的增删改是在内存中直接操作的。Redis采用持久化的方式将内存中的数据保存到磁盘。

        Redis的持久化的方式有两种，其中一种是RDB机制，另一种AOF机制。

        RDB机制采用的是快照模式,也是Redis默认的持久化机制（会在src目录下生成dump.rdb文件），重启Redis时会把dump.rdb的文件读取到内存中。

      那么什么情况会执行快照模式？

        1.服务器正常关闭会发生快照。

        2.当key满足一定条件的情况下会发生快照。我用vi编译器打开Redis的配置文件redis.config中有如下配置段

在这里小编讲给大家解释一下配置文件这3行指令的含义：

             save 900 1表示在900s内被更改键的个数大于1时就照一次快照保存（添加，修改或删除）

            save 300 10表示在300s内被更改键的个数大于10时就照一次快照保存

            save 60 10000表示在60s内被更改键的个数大于10000时就照一次快照保存

            上面所说的3个条件只要发生其中之一就会快照保存。

         3.当用户使用save指令或者bgsave指令会发上快照

            执行save命令时redis的同步，（会阻塞redis进程，阻塞期间，服务器无法响应其他的处理，直到执行完成为止）此过程会阻碍来自客户端的所有请求。

            执行Bgsave是异步的，进行快照的同时还能处理来自客户端的请求。（执行此命令的时候，redis会fork出一个子进程去完成备份持久化，而不会影响redis处理其他的请求）（执行Bgsave redis返回OK表示开始快照lastsave返回最近一次快照时间）。

 优点：

         保存数据块，还原数据也快。

         dump.rdb用于做redis的备份文件，数据量小，只需要dump.rdb文件就可以还原数据库。

  缺点：

          当redis断电时可能会造成部分数据丢失。

            在一般情况下，每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。

        AOF机制使用日志功能来保存数据操作， 只保存导致key变化的语句。因为AOF机制不是默认的机制，因此我们要在Redis的配置文件redis.config中将no改为yes,启动aof机制。

   aof保存的数据会保存在appendonly.aof文件 中，当然我们也可以修改文件的名字。 

在配置文件中可以对名字进行修改（红色部分为生成文件的名字）

       AOF执行持久化的方式分为3种，它们分别为：

        每秒同步 (默认)：每秒进行一次AOF保存数据。 安全性低，但是节省系统资源。

        每修改同步：只要有key变化就进行一次AOF保存数据。比较安全，但浪费效率低。

        不同步 ：不进行任何持久化操作 。

        在redis.config配置文件中

            其中的always代表着每修改同步，everysec代表着美秒同步，no代表着不同步。

  优点：

          极少量的占用内存。（跟适合于内存比较小的计算机）

   缺点：

         同样的数据量AOF的 日志文件会很大。

        根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间。