redis数据持久化之RDB和AOF

引言

1、RDB持久化方式能够在指定的时间间隔能对数据进行快照存储备份.

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

3、若程序数据只要求在服务器运行的时候存在,那么你可以不使用任何持久化方式.

4、可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB快照

快照（snapshotting）可以将存在于某一时刻的所有数据都写入硬盘里面. 具体的配置在 redis.conf 中，如下

save  60  1000         ## 在给定的秒数和给定数量的写操作次数达到时将触发生成快照；当60秒内有1000次写入就会触发快照
stop-writes-on-bgsave-error  no   ## 当最近的一次快照保存有错误导致失败，这时redis会默认无法写入，设置为no，不允许再次写入（当设置了redis服务器和监控时）
rdbcompression  yes   ## 转储rdb文件时，是否使用LZF压缩字符对象
dbfilename  dump.rdb    ## 存储的快照文件名

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。你也可以通过调用 SAVE或者 BGSAVE ， 手动让 Redis 进行数据集保存操作.

RDB工作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:

1、Redis 调用forks()创建子进程，也就是说同时拥有父进程和子进程.

2、子进程将数据集写入到一个临时 RDB 文件中.

3、当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件.

RDB优点

1、RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集，非常适用于灾难恢复.

2、RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB缺点

1、当系统宕机，用户将丢失最近一次生成快照之后更改的所有数据。频率和save后面的参数有关，因此，快照只适用于那些即使丢失了一部分数据也不会造成问题的应用程序.

2、RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF持久化

AOF持久化会将被执行的写命令写入到AOF文件的末尾，以此来记录数据的变化.

appendonly yes   ##是否使用AOF持久化
appendfilename "appendonly.aof"
appendfsync everysec   ##同步频率
no-appendfsync-on-rewrite no   ##进行压缩时是否进行同步操作
auto-aof-rewrite-percentage 100   ##多久执行一次AOF压缩
auto-aof-rewrite-min-size 64mb
dir ./     ##aof文件的保存目录

AOF工作方式

1、Redis 执行 fork() ，现在同时拥有父进程和子进程.

2、子进程开始将新 AOF 文件的内容写入到临时文件.

3、对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的.

4、当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾.

AOF优点

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

2、AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,也可使用redis-check-aof工具修复这些问题.

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

4、AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态.

AOF缺点

1、对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积.

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

appendfsync参数

选项	同步频率
always	每个redis写命令都同步写入磁盘，会严重降低redis的速度（存在写入放大的问题，降低磁盘的使用寿命）
everysec	每秒执行一次同步，显式的将多个写命令同步到磁盘（当磁盘忙于写操作时，redis会优雅的放慢自己的速度以适应磁盘的写入速度）
no	让系统决定在何时进行同步（若系统宕机将导致不定数量的数据丢失）

AOF文件损坏怎么办？

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

1、为现有的 AOF 文件创建一个备份.

2、使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复:

$ redis-check-aof –fix

3、（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处.

4、重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复.

重写/压缩 AOF文件

AOF持久化存在两个问题: AOF文件只追加，随着应用的运行，文件的体积会越来越大; 当系统宕机后采用AOF文件恢复数据，AOF文件过大使得redis数据恢复操作耗时过长（过大可能导致系统的挂起）. 重写（去除冗余命令，例如redis进行了100次自增1的操作，通过重写合并为incr 100）命令能较好的解决这个问题，同理，redis也会创建子线程来负责对AOF文件的重写. 故而，在快照持久化方法中存在的创建子线程导致的性能问题和内存占用问题也同样存在于AOF持久化方法中，如下配置，表示当aof文件的大小大于64mb，且aof的体积比上一次大了100%的时候触发AOF重写

auto-aof-rewrite-percentage 100   
auto-aof-rewrite-min-size 64mb

更多的关于redis数据备份和容灾备份请移步至参考文章:redis官网