[大数据] Redis从入门到入坟系列文章（十二）：持久化

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 大数据 -> Redis从入门到入坟系列文章（十二）：持久化 -> 正文阅读

[大数据]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快照备份的效果：

先找到dump.rdb文件，手动删除，我电脑是win7，目录在C:\Users\Administrator
然后启动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>
```
退出服务后，我们发现刚才删掉的dump.rdb又有了，说明成功的生成了备份文件。
然后我们再启动redis，发现刚才存储的数据都还在。这说明重新启动redis时，自动从dump.rdb文件中加载了数据到redis。
再次关闭并退出redis，且手动删除dump.rdb的数据。
再次启动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的效果：

通过命令 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"

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

#save 900 1
#save 300 10
#save 60 10000
关闭并退出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 。

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