redis的持久化方式：RDB和AOF

   数据持久化通俗讲就是把数据保存到磁盘上，保证不会由于断电等因素丢失数据。

   

       Redis是一种高级key-value数据库。它跟memcached相似，不过数据能够持久化，并且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。因此Redis也能够被当作是一个数据结构服务 器。

      Redis的全部数据都是保存在内存中，而后不按期的经过异步方式保存到磁盘上(这称为“半持久化模式”)；也能够把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

      redis支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另外一种是Append-only file（缩写aof）的方式。

 


1.Snapshotting（RDB）

    默认redis是会以快照的形式将数据持久化到磁盘的（一个二进 制文件，dump.rdb，这个文件名字能够指定），在配置文件中的格式是：save N M表示在N秒以内，redis至少发生M次修改则redis抓快照到磁盘。固然咱们也能够手动执行save或者bgsave（异步）作快照。

    下面是默认的快照保存配置

save 900 1  #900秒内若是超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000

工做原理：

1.当redis须要作持久化时，redis会fork一个子进程。

2. 父进程继续处理client请求，子进程负责将内存内容写入到临时RDB文件。因为os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面建立副本，而不是写共享的页面。因此子进程的地址空间（地址空间（address space）表示任何一个计算机实体所占用的内存大小）内的数 据是fork时刻整个数据库的一个快照。

3.当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是能够copy-on-write（Copy-on-write 写时复制      在对数据进行修改的时候，不会直接在原来的数据位置上进行操做，而是从新找个位置修改，这样的好处是一旦系统忽然断电，重启以后不须要作Fsck.）

      client 也可使用save或者bgsave命令通知redis作一次快照持久化。

      save操做是在主线程中保存快照的，因为redis是用一个主线程来处理全部 client的请求，这种方式会阻塞全部client请求。因此不推荐使用。

     

      另外一点须要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。若是数据量大的话，并且写操做比较多，必然会引发大量的磁盘io操做，可能会严重影响性能。

     另外因为快照方式是在必定间隔时间作一次的，因此若是redis意外down掉的话，就会丢失最后一次快照后的全部修改。若是应用要求不能丢失任何修改的话，能够采用aof持久化方式。

2.Append-only file（AOF）

     AOF定义：以日志的形式记录每一个操做，将Redis执行过的全部指令所有记录下来（读操做不记录），只许追加文件但不能够修改文件，Redis启动时会读取AOF配置文件重构数据。

换句话说，就是Redis重启就会根据日志内容从头至尾执行一次来完成数据的恢复工做。

      AOF比快照方式有更好的持久化性，是因为在使用AOF持久化方式时,redis会将每个收到的写命令都经过write函数追加到文件中(默认是 appendonly.aof)。

     

     当redis重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。固然因为os会在内核中缓存 write作的修改，因此可能不是当即写到磁盘上。这样aof方式的持久化也仍是有可能会丢失部分修改。

    不过咱们能够经过配置文件告诉redis咱们想要 经过fsync函数强制os写入到磁盘的时机。

 有三种方式以下（默认是：每秒fsync一次）

appendonly yes              //启用aof持久化方式
# appendfsync always      //每次收到写命令就当即强制写入磁盘，最慢的，可是保证彻底的持久化，不推荐使用
appendfsync everysec     //每秒钟强制写入磁盘一次，在性能和持久化方面作了很好的折中，推荐
# appendfsync no    //彻底依赖os，性能最好,持久化没保证

Tip:

　　一.RDB与AOF同时开启  默认先加载AOF的配置文件

　　二.相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB

　　三.AOF运行效率慢于RDB,可是同步策略效率好，不一样步效率和RDB相同

1.表示是否开启AOF持久化：

　　appendonly yes(默认no,关闭) 

2.AOF持久化配置文件的名称：

　　appendfilename "appendonly.aof"

3.AOF持久化策略(默认每秒)：

　　appendfsync always (同步持久化，每次发生数据变动会被当即记录到磁盘，性能差但数据完整性比较好)

　　appendfsync everysec (异步操做，每秒记录，若是一秒钟内宕机，有数据丢失)

　　appendfsync no  （不一样步）

4.AOF配置文件损坏修复方法：

　　进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称

5.AOF的Rewrite(重写) ：

　　定义：AOF采用文件追加的方式持久化数据，因此文件会愈来愈大，为了不这种状况发生，增长了重写机制

当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留能够恢复数据的最小指令集，可使用命令bgrewriteaof

原理：当AOF增加过大时，会fork出一条新的进程将文件重写(也是先写临时文件最后rename)，遍历新进程的内存数据，每条记录有一条set语句。

重写AOF文件并无操做旧的AOF文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件（有点相似快照）

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

　　auto-aof-rewrite-percentage 100  （一倍）

　　 auto-aof-rewrite-min-size 64mb

6.RDB与AOF的选择：

作备份：当数据量大，且对恢复速度有要求，而且数据的一致性要求不高的话，能够只使用RDB

只作缓存：不用开启任何的持久化方式

二者都开启的建议：RDB数据不实时，同时使用二者时服务器只会找AOF文件，可不能够只使用AOF?做者建议不要，由于RDB更适合备份数据库(AOF在不断变化，很差备份)

快速重启，并且不会又AOF可能潜在的BUG,留做万一的手段。

运维上的想法

其实快照和aof同样，都使用了Copy-on-write技术。屡次试验发现每次作数据dump的时候，内存都会扩大一倍，这个时候会有三种状况：

一：物理内存足以知足，这个时候dump很是快，性能最好

二：物理内存+虚拟内存能够知足，这个时候dump速度会比较慢，磁盘swap繁忙，服务性能也会降低。所幸的是通过一段比较长的时候数据dump完成了，而后内存恢复正常。这个状况系统稳定性差。

三： 物理内存+虚拟内存不能知足，这个时候dump一直死着，时间久了机器挂掉。这个状况就是灾难！

若是数据要作持久化又想保证稳定性，建议留空一半的物理内存。若是以为没法接受仍是有办法，下面讲：

     快照和aof虽然都使用Copy-on-write，但有个不一样点，快照你没法预测redis何时作dump，aof能够经过bgrewriteaof命令控制dump的时机。

根据这点我能够在一个服务器上开启多个redis节点(利用多CPU)，使用aof的持久化方式。

      例 如在24G内存的服务器上开启3个节点，天天用bgrewriteaof按期从新整理数据，每一个节点dump的时间都不同，这 样理论上每一个节点能够消耗6G内存，一共使用18G内存，另外6G内存在单个节点dump时用到，内存一下多利用了6G！ 固然节点开的越多内存的利用率也越高。若是带宽不是问题，节点数建议 = CPU数。