Redis从入门到入坟系列文章（十二）：持久化

今天来了解下Redis的持久化。Redis提供了两种持久化方式：RDB和AOF。

• RDB：能够在指定的时间间隔能对你的数据进行快照存储
• AOF：记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。

RDB：

我们先来看看RDB持久化方式。RDB是默认开启的。有关RDB的默认配置，我们打开文件reids.conf（windows系统是redis.windows.conf），其中相关的配置主要有如下几项：

        save 900 1

        save 300 10

        save 60 10000

        stop-writes-on-bgsave-error yes

        rdbcompression yes

        rdbchecksum yes

        dbfilename dump.rdb

        dir ./

• 前面三个save选项，表示备份的频率。第一个是900秒内至少有1个键被更改，则进行一次备份；第二个是300秒内至少有10个键被更改，则进行一次备份；第三个是60秒内至少有10000个键被更改，则进行一次备份。
• stop-writes-on-bgsave-error选项，是在备份出错后，是否继续执行写命令，默认配置为yes。 
• rdbcompression选项，表示是否对备份文件进行压缩，默认值为yes。
• rdbchecksum选项，是在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，默认值为yes。
• dbfilename选项，保存备份文件的名称，默认为dump.rdb。
• dir选项，为保存备份文件的路径，默认在用户的根目录下。

     接下来举个简单的例子，看看rdb快照备份的效果：

1. 先找到dump.rdb文件，手动删除，我电脑是win7，目录在C:\Users\Administrator
2. 然后启动redis，随便添加点数据，比如新增两个key：key1、key2，然后使用SHUTDOWN命令关闭退出服务。

   127.0.0.1:6379> SET key1 hello
   OK
   127.0.0.1:6379> SET key2 world
   OK
   127.0.0.1:6379> SHUTDOWN
   not connected>

3. 退出服务后，我们发现刚才删掉的dump.rdb又有了，说明成功的生成了备份文件。
4. 然后我们再启动redis，发现刚才存储的数据都还在。这说明重新启动redis时，自动从dump.rdb文件中加载了数据到redis。
5. 再次关闭并退出redis，且手动删除dump.rdb的数据。
6. 再次启动redis，发现刚才添加的数据都不存在了。

我们再来看看rdb的工作方式：

其实rdb的工作方式就是怎么把数据保存到dump.rdb，当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

• Redis 通过bgsave命令会调用forks，同时拥有父进程和子进程。
• 父进程继续处理客户端发送过来的请求，而子进程负责执行将快照写入硬盘，即写入到一个临时 RDB 文件中。
• 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
• 我们在主从备份的时候，会触发bgsave命令。 当从机连接主机后，会发送一条sync命令来开始一次复制操作，此时主机会开始一次bgsave操作，并在bgsave操作结束后，向从机发送快照数据实现数据同步。

最后再来看看rdb有哪些优点和缺点。

1、优点：

• RDB是一个非常紧凑的文件，它保存了某个时间点的数据集，非常适用于数据集的备份，比如你可以在每个小时报保存一下过去24小时内的数据，同时每天保存过去30天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
• RDB是一个紧凑的单一二进制文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

2、缺点：

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然可以配置不同的save时间点，但是比如每隔5分钟对数据集有100个写的操作，通常就会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你很可能会最多丢失这5分钟的数据。
• RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒。虽然AOF也需要fork，但是可以调节重写日志文件的频率来提高数据集的耐久度。

 AOF：

        下面我们再来看看AOF这种持久化方式。 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

        由于Redis中RDB默认是开启的，而AOF默认是关闭的，所以我们需要手动开启AOF。我们打开redis.windows.conf文件，找到appendonly参数，其默认值为no，表示不开启AOF，我们改成yes，则开启AOF：

 appendonly yes 

还有几个跟AOF相关的属性如下：

        appendfilename "appendonly.aof"

        appendfsync everysec

        aof-load-truncated yes

        no-appendfsync-on-rewrite no

        auto-aof-rewrite-percentage 100

        auto-aof-rewrite-min-size 64mb                                                                                       

• appendfilename：表示生成的AOF备份文件的文件名，默认为 appendonly.aof。
• appendfsync：表示备份的策略，默认值为everysec，表示每秒最多fsync一次；还有两个值为always(表示每次write都会fsync一次)、no(表示write后也不fsync，由操作系统自动调度刷磁盘，性能是最好的)。
• aof-load-truncated：表示在恢复Redis时，会忽略最后一条可能存在问题的命令。默认值yes。即在AOF写入时，可能存在指令写错的问题(比如突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败。
• no-appendfsync-on-rewrite：表示对aof文件进行压缩时，是否执行同步操作。
• auto-aof-rewrite-percentage和auto-aof-rewrite-min-size：aof文件增长比例，表示当前aof文件比上次重写的aof文件的百分之多少时会再次进行重写，默认为100%；如果之前没重写，则以启动时的aof文件大小为依据，同时还要求aof的文件的大小至少要大于auto-aof-rewrite-min-size参数的值，默认值为64M。

我们看看aof的效果：

1. 通过命令 config set appendonly yes ，把appendonly参数设置为yes

   127.0.0.1:6379> config get appendonly
   1) "appendonly"
   2) "no"
   127.0.0.1:6379> config set appendonly yes
   OK
   127.0.0.1:6379> config get appendonly
   1) "appendonly"
   2) "yes"

2. 然后随便添加一个key，我们打开文件目录，发现这时候有了appendonly.aof文件。
3. 然后为了不让rdb影响我们查看aof备份的效果，把以下参数改成如下：

   save ""

   #save 900 1
   #save 300 10
   #save 60 10000

4. 关闭并退出Redis服务，然后重启服务，发现之前保存的key都还在。

127.0.0.1:6379> KEYS *
1) "key2"
2) "key1"
127.0.0.1:6379> SHUTDOWN
not connected> KEYS *
1) "key2"
2) "key1"

       接下里我们总结下AOF有哪些优点和缺点：

1、优点：

• 使用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 执行之前的状态。

    2、缺点：

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

   如何选择持久化方式

        因为RDB可能会丢失几分钟内的数据，如果可以接受，那么我们可以只用RDB持久化。还有一部分用户，只使用 AOF 持久化，但不推荐这种方式。因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

        综上，一般来说，建议同时开启两种持久化方式。