Redis 持久化之RDB和AOF

1.什么是持久化？

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

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

    由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁 盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。那么这两种持久化方式有什么区别呢，改如何选择呢？网上看了大多数都是介绍这两 种方式怎么配置，怎么使用，就是没有介绍二者的区别，在什么应用场景下使用。

 

2. Redis持久化之RDB( snapshotting ):

2.1 Redis持久化之RDB是什么：

    RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

    实际操作过程是Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。

     RDB 保存的是hump.rdb文件。

 

2.2 fork进程是什么：

     Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

2.3 Redis持久化之RDB 配置和触发

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

上面三个满足任一条件是将会触发RDB快照。

    • 配置文件中默认的快照配置,冷拷贝后重新使用,可以：cp dump.rdb dump_bk.rdb

    • 命令save或者是bgsave

        Save：save时只管保存，其它不管，全部阻塞

        BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave,命令获取最后一次成功执行快照的时间

    • 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

2.4 如何恢复

    • 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

    • CONFIG GET dir获取目录  

    • 进行恢复：mv dump_bk.rdb dunp.rdb

2.5 优势

    • 适合大规模的数据恢复

    • 对数据完整性和一致性要求不高

2.6 劣势

    • 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改.

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

2.7 如何停止

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

 

 

3.Redis持久化之AOF（append-only file）

3.1 Redis持久化之AOF是什么：

    AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

    Aof保存的是appendonly.aof文件。

3.2 Redis持久化之AOF 配置：

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no          #从不同步。高效但是数据不会被持久化。

3.3 AOF启动之修复和恢复

3.3.1 正常恢复

    • 启动：设置Yes;修改默认的appendonly no，改为yes

    • 将有数据的aof文件复制一份保存到对应目录(config get dir)

    • 恢复：重启redis然后重新加载

3.3.2 异常恢复

    • 启动：设置Yes

    • 备份被写坏的AOF文件

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

    • 恢复：重启redis然后重新加载

3.4 Rewrite

3.4.1 是什么：

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

3.4.2 重写原理：

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

3.4.3 触发机制

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

3.5 优势：

     每秒同步：appendfsync always 同步持久化每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好。

     每修改同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失。

     不同步：appendfsync no  从不同步。

3.6 劣势

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

    Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

 

4.总结

    • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

    • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些,命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

    • 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。

 

5.性能建议   

      因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 9001这条规则。

      如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

     如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较aster/Slave中的RDB文件，载入较新的那个。

  

6.RDB 和 AOF选择

    redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。仅使用 RDB，会导致你丢失很多数据；仅使用 AOF，有两个问题：第一，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；第二，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；