redis 持久化介绍及选择

 

Redis 提供了不一样级别的持久化方式:

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

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

RDB的优势：

RDB是一个很是紧凑的文件，它保存了某个时间点得数据集,很是适用于数据集的备份，好比你能够在每一个小时报保存一下过去24小时内的数据，同时天天保存过去30天的数据,这样即便出了问题你也能够根据需求恢复到不一样版本的数据集。

RDB是一个紧凑的单一文件，很方便传送到另外一个远端数据中心，很是适用于灾难恢复。

RDB在保存RDB文件时父进程惟一须要作的就是fork出一个子进程，接下来的工做所有由子进程来作，父进程不须要再作其余IO操做，因此RDB持久化方式能够最大化redis的性能。

与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些。

RDB的缺点

若是你但愿在redis意外中止工做（例如电源中断）的状况下丢失的数据最少的话，那么RDB不适合你。虽然你能够配置不一样的save时间点(例如每隔5分钟而且对数据集有100个写的操做)，是Redis要完整的保存整个数据集是一个比较繁重的工做，你一般会每隔5分钟或者更久作一次完整的保存，万一在Redis意外宕机,你可能会丢失几分钟的数据。

RDB 须要常常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是很是耗时的，可能会致使Redis在一些毫秒级内不能响应客户端的请求。若是数据集巨大而且CPU性能不是很好的状况下,这种状况会持续1秒，AOF也须要fork，可是你能够调节重写日志文件的频率来提升数据集的耐久度。

AOF 优势

使用AOF 会让你的Redis更加耐久， 你可使用不一样的fsync策略，无fsync，每秒fsync，每次写的时候fsync，使用默认的每秒fsync策略，Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失1秒的数据。

AOF文件是一个只进行追加的日志文件，因此不须要写入seek，即便因为某些缘由(磁盘空间已满，写的过程当中宕机等等)未执行完整的写入命令，你也也可以使用redis-check-aof工具修复这些问题。

Redis 能够在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操做是绝对安全的，由于 Redis 在建立新 AOF 文件的过程当中，会继续将命令追加到现有的 AOF 文件里面，即便重写过程当中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件建立完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操做。

AOF 文件有序地保存了对数据库执行的全部写入操做， 这些写入操做以 Redis 协议的格式保存， 所以 AOF 文件的内容很是容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也很是简单： 举个例子， 若是你不当心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要中止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就能够将数据集恢复到 FLUSHALL 执行以前的状态。

AOF 缺点

对于相同的数据集来讲，AOF 文件的体积一般要大于 RDB 文件的体积。

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

RDB 配置实例：

save 900 1 #900秒内1个key改动
save 300 10  #300秒内10个key改动
save 60 1000  #60秒内1000个key改动

表示知足上面三个条件的任何一条会进行一次持久化操做

AOF 配置：

首先要开启aof配置

# appendfsync always  #每次有新命令追加到 AOF 文件时就执行一次 fsync ：很是慢，也很是安全
appendfsync everysec  #每秒 fsync 一次：足够快（和使用 RDB 持久化差很少），而且在故障时只会丢失 1 秒钟的数据。
# appendfsync no  #从不 fsync ：将数据交给操做系统来处理。更快，也更不安全的选择。

 推荐选择第二种方式

使用选择：

另外须要主要的是在生产服务器上开启持久话，每次进行持久化时会对redis服务形成一些影响，rdb写入和aof文件重写时对服务的IO和cpu都有影响，

严重状况下在持久化时可能会形成redis阻塞，建议使用redis集群或主从同步，在生产服务上关闭持久化，在slave上开启持久化。

若是必须开启持久化，也要兼顾效率，建议使用aof，采用每秒fsync一次的方式