Redis数据持久化

Redis作为一个内存数据库，数据是以内存为载体存储的，那么一旦Redis服务器进程退出，服务器中的数据也会消失。为了解决这个问题，Redis提供了持久化机制，也就是把内存中的数据保存到磁盘当中，避免数据意外丢失
Redis提供了两种持久化方案：RDB持久化和AOF持久化，一个是快照的方式，一个是类似日志追加的方式

RDB(Redis Database) ，将某一时刻的所有数据保存到一个 RDB 文件中。
AOF(append-only-file) ，当Redis服务器执行写命令的时候，将执行的写命令保存到 AOF 文件中。

RDB(Redis DataBase)快照持久化

在指定的时间间隔，执行数据集的时间点快照

实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。

这个快照文件就称为RDB文件(dump.rdb)其中，RDB就是Redis DataBase的缩写，该文件是一个压缩过的二进制文件，可以通过该文件还原快照时的数据库状态。
RDB文件默认为当前工作目录下的dump.rdb，可以根据配置文件中的dbfilename和dir设置RDB的文件名和文件位置

手动触发快照

Redis提供了两个命令来生产RDB文件，分别是save和bgsave

save 在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
- bgsave redis会在后台异步进行快照操作，不阻塞快照同时还可以相应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程
- Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。
- fork是什么？在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后会exec系统调用，处于效率考虑，尽量避免膨胀
- 可以通过lastsave命令获取最后一次成功执行快照的时间

自动间隔触发快照

在配置文件中设置save <seconds> <changes>规则，可以自动间隔性执行bgsave命令

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

save 表示在seconds秒内，至少有changes次变化，就会自动触发bgsave命令

save 900 1 当时间到900秒时，如果至少有1个key发生变化，就会自动触发bgsave命令创建快照
save 300 10 当时间到300秒时，如果至少有10个key发生变化，就会自动触发bgsave命令创建快照
save 60 10000 当时间到60秒时，如果至少有10000个key发生变化，就会自动触发bgsave命令创建快照

如何恢复

将备份文件(dump.rdb)移动到 Redis 安装目录并启动服务即可

备份成功后故意用flushdb清空redis，看看是否可以恢复数据

执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
物理恢复，一定要将服务产生的RDB文件备份一份，然后分机隔离，避免生产上物理损坏后备份文件也挂了。

RDB快照文件

如何检查修复dump.rdb文件？

进入到redis安装目录，执行redis-check-rdb命令 redis-check-rdb ./redisconfig/dump.rdb

哪些情况会触发RDB快照

配置文件中默认的快照配置
手动save/bgsave命令
执行flushdb/fulshall命令也会产生dump.rdb文件，但是也会将命令记录到dump.rdb文件中，恢复后依旧是空，无意义
执行shutdown且没有设置开启AOF持久化
主从复制时，主节点自动触发

如何禁用快照

动态所有停止RDB保存规则的方法：redis-cli config set value ""
手动修改配置文件

RDB优化配置项详解

配置文件SNAPSHOTTING模块

save <seconds> <changes>：配置快照保存条件
dir：配置快照保存目录地址
dbfilename：配置快照的文件名
stop-writes-on-bgsave-error：
默认yes，如果配置成no，表示不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的请求
rdbcompression：
默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum：
默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdb-del-sync-files：
在没有持久化的情况下删除复制中使用的RDB文件。默认情况下no，此选项是禁用的。

RDB优劣

优势

RDB是Redis 数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。
RDB非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3(可能已加密）的压缩文件。
RDB最大限度地提高了Redis 的性能，因为Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘I/О或类似操作。
与AOF 相比，RDB允许使用大数据集更快地重启。
在副本上，RDB支持重启和故障转移后的部分重新同步。

总结

适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性要求不高
RDB文件在内存中的加载速度要比AOF快很多

劣势

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

小总结：