【redis 四】一文搞懂redis持久化之RDB

前言：

redis持久化分为RDB和AOF，此篇博文着重讲解RDB方式的持久化。演示系统 centos7。

1、官网说明

地址：https://redis.io/topics/persistence
以下内容为有道词典翻译

Redis持久性

RDB持久性按指定的时间间隔执行数据集的时间点快照。

RDB的优势

RDB是Redis数据的非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时存档一次RDB文件，并在30天之内每天保存一次RDB快照。这使您可以在灾难情况下轻松还原数据集的不同版本。
RDB对于灾难恢复非常有用，它是一个紧凑的文件，可以传输到远程数据中心或Amazon S3（可能已加密）上。
RDB最大限度地提高了Redis的性能，因为Redis父进程为了持久化而需要做的唯一工作就是分叉一个孩子，其余所有工作都要做。父实例将永远不会执行磁盘I / O或类似操作。
与AOF相比，RDB允许大型数据集更快地重启。

RDB的缺点

如果您需要最大程度地减少数据丢失的可能性（如果Redis停止工作，例如在断电之后），则RDB不好。您可以在生成RDB的位置配置不同的保存点（例如，在至少五分钟之后，对数据集进行100次写入，但是您可以有多个保存点）。但是，通常会每隔五分钟或更长时间创建一次RDB快照，因此，如果Redis出于任何原因在没有正确关闭的情况下停止工作，则应该准备丢失最新的数据分钟。
RDB需要经常使用fork（）才能使用子进程将其持久化在磁盘上。如果数据集很大，Fork（）可能很耗时，并且如果数据集很大且CPU性能不佳，则可能导致Redis停止为客户端服务几毫秒甚至一秒钟。AOF还需要fork（），但您可以调整要重写日志的频率，而无需权衡持久性。

2、简单理解

看了官网说的那样，似乎有点生硬难懂，接下来用硅谷阳哥的笔记中的内容做下说明：RDB持久化就是指在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

RDB是redis默认持久化的方式，不需要进行配置，默认就使用这种机制，那么这种机制在redis的配置文件 redis.conf中默认是如何设置的，请看配置文件源码：

#   after 900 sec (15 min) if at least 1 key changed
save 900 1
#   after 300 sec (5 min) if at least 10 keys changed
save 300 10
#   after 60 sec if at least 10000 keys changed
save 60 10000

以上第一个数字表示的是时间，第二个数字表示的是变化的key,
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。实际上，只要满足以上任何一个条件，redis就会持久化一次（也就是往磁盘上复制一份数据） 当save ""时，表示删除之前配置的所有save

3、如何触发RDB快照（SNAPSHOTTING）

首先我们要知道RDB默认生成的文件为dump.rdb，可以用来恢复数据（备份文件）

（1）save触发快照

如下，我先打开redis的客户端，set了三个值，分别为kv ok an，上边默系统给出的默认

save 900 1
save 300 10
save 60 10000

我自己测了第一个，就是等了大概十五分钟，出现了dump.rdb文件，这里你们可以去测，这里我们强制触发RDB快照。
就是输入save,然后回车，如下图

完成之后，我们打开我们的data文件夹，出现了了dump.rdb

此时我们将dump.rdb备份一下，正确的姿势是备份到另一台服务器，但是呢，这里只是为了演示，我就在相同路径下备份一个别名的文件吧
命令cp dump.rdb dump_new.rdb

接下来shutdown我们的客户端

然后再次启动我们的redis客户端，和服务端，进入到客户端输入keys *，如下图，出现了我们刚刚持久化后的键 a、k、o，成功恢复。

上面我们还备份了一个叫做dump_new.rdb的文件，这个文件刚才说过应该出现在另一台服务器上，是为了解决如果我的这台服务器崩溃问题，此时还是做一个小测试吧，输入
flushall，清空所有的数据库，这里要注意，它也会产生dump.rdb文件，但里面是空的，自己玩玩用这个命令可以，要是在生产服务器，或者测试服务器上输入此命令，感觉你的队友会干死你。突然自己的数据没有了，多么崩溃的事情。此时我们get a 返回nil 证明我们已经将数据清空了

获取目录：输入命令CONFIG GET dir,目录为data

此时我们删除data 下的dump.rdb文件，然后将dump_new.rdb文件重命名为dump.rdb，因为redis默认解析名字为dump.rdb的文件。

此时重新启动你的redis服务端和客户端：
输入keys *发现数据恢复

（2） 命令 bgsave

可以通过lastsave命令获取最后一次成功执行快照的时间，客户端可以通过 LASTSAVE 命令查看相关信息，判断 BGSAVE 命令是否执行成功。

接下来说下SAVE和BGSAVE的区别：
SAVE 保存是阻塞主进程，客户端无法连接redis，等SAVE完成后，主进程才开始工作，客户端可以连接

BGSAVE 是fork一个save的子进程，在执行save过程中，不影响主进程，客户端可以正常链接redis，等子进程fork执行save完成后，通知主进程，子进程关闭
（3）flushall （慎用）
这个命令也会产生dump.rdb文件，但里面是空的，无意义

4、动态停止RDB保存规则的方法：

redis-cli config set save ""

5、RDB的优缺点小总结

优点：

适合大规模数据恢复
节省空间
对数据完整性和一致性要求不高
恢复速度快

缺点：

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，数据量大的时候，耗性能