Redis(4):Redis持久化简介

1.为什么要做持久化？持久化的意义是什么？

(1).Redis持久化的意义

        看到上述问题你可能想说，做持久化的意义不就是将数据保存到磁盘上？对，大体是这样。redis持久化的意义就是为了容灾，进行故障恢复，试想一下，当并发量很大的时候，redis整个挂掉了，如果没有进行持久化的话，缓存里的数据都没了，大量的请求都不能直接命中就会去数据库中查找，就相当于mysql直接面对高并发，mysql承受高并发的能力并不高，这样就会导致Mysql整个挂掉，mysql挂掉的话就会导致redis里的数据无法恢复，因为redis里的数据是从mysql里面查出来的。

(2).Redis持久化的种类

        redis的持久化主要有两种类型，rdb和aof。他们俩可以同时开启，但是redis会优先使用aof进行恢复，因为aof相对rdb来说数据更全。当然，如果只是把Redis当作纯内存的缓存来用，就可以把rdb和aof都禁用掉。

2.RDB持久化机制优缺点详解

        rdb是一定的机制对内存中的数据进行周期性的持久化，生成后缀为.rdb的快照文件。

rdb持久化简图

(1).rdb持久化的优点

        (a).rdb会生成多个数据文件，每个文件都代表的是某个时刻的redis中的数据,rdb是非常适合做冷备份的，可以定时的将生成的rdb文件上传到云服务中，当你想要恢复某个时刻的数据时只要将云服务器上的rdb文件下载下来即可恢复了。 那aof可以用来做冷备吗？答案是可以的，但是aof只生成一个文件，你可以定时的将aof文件复制出来。但是，更适合做冷备的其实时rdb,他的优势在于，他的定时是由redis来控制的，使用aof做冷备的话还要你自己写一些shell脚本之类的去定时的将文件复制出来，还有就是在最坏的情况下，rdb恢复数据的速度比aof更快。

        (b).rdb对Redis提供对外的读写服务的影响非常的小，可以让Redis保持比较高的性能，生成新的rdb的时候是Redis fork了一个子进程，让子进程执行磁盘io操作进行持久化。aof相对来说影响redis大一些，因为aof每次都是要写文件的，虽然写入的是os cache,但是还是要一定的时间开销，相对rdb来说要慢一些。

        (c).为什么说rdb恢复数据比aof快呢？这里解释一下。因为rdb存储的就是Redis某一时刻的数据文件，恢复的时候只要将文件加载到内存就行了，而aof存储的是一系列的操作指令，恢复数据的时候要回放和执行所有的操作，所以aof恢复数据的速度相对来说要慢一些。

        综上所述，如果要做冷备的话，还是rdb更合适一些。

(2).rdb持久化的缺点

        (a).如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据，这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。

        (b).RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒,一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的。

3.AOF持久化机制详解

        AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。

aof持久化机制简图

(1).aof持久化的优点

(a).AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

(b).AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。

(c).AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

(d).AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

(2).aof持久化的缺点

(a).对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。

(b).AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成每写入一条数据就fsync一次，那么redis的QPS就会大幅度降低。

(c).以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

(d).唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适。

4.aof和rdb应该如何选择？

(1).不要仅仅使用RDB，因为那样会导致你丢失很多数据。

(2).也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。

(3).综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。