Redis的持久化方式以及备份策略

Redis持久化的意义在于故障恢复。如果只是将Redis服务的数据存放在内存中，如果遇到突发故障时，例如Redis宕机，重启Redis服务后，内存中的数据会全部丢失。为保障数据的可恢复，就需要将Redis服务的数据进行必要的持久化

现在的Redis提供三种持久化方式，RDB持久化、AOF持久化、以及混合持久化。

1、RDB持久化

RDB(Redis DataBase)，Redis快照方式持久化。RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保 存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来 定义快照的周期。

文件以二进制形式进行压缩存储，文件小，恢复速度快。

触发RDB的两种方式：

sava、bgsave，这两个是Redisd的后台命令，不需要手动配置。当配置了自动生成[rdb]文件后台采用的是bgsave方式。

sava

主线程操作，同步执行，会阻塞其它命令的执行。执行[save]命令时，如果时间过长，后续请求会被阻塞，客户端新发送所有命令都会被拒绝。

bgsave

写时复制，异步执行，不会阻塞其它命令的执行，会fork一个子进程进行操作，但这样比较消耗内存。主进程依旧保持与客户端的连接，正常执行读写命令。

写时复制，不光会操作内存区存储的数据，还会操作副本[rdb]文件中同时写本次操作的数据。

​

RDB配置

实现上主要通过配置【redis.conf】文件实现，在配置文件中有save的相关参数

# Redis默认的配置
save 900 1
save 300 10
save 60 10000

# m 代表秒数，n 代表次数，表示 m 秒内发生 n 次变化时，会触发Redis的bgsave
save m n
# 在上面的默认配置参数中
# 就表示 在900秒内，发生1次数据更改
# 在300秒内，发生10次数据更改
# 在60秒内，发生10000次数据更改
# 都会进行Redis的bgsave

RDB文件数据恢复

当 Redis 服务器重启时，Redis服务根据【redis,conf】配置文件中的【dir】文件路径，检测到 dump.rdb 文件后，会自动加载进行数据恢复。

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
# DB将被写入到这个目录中，并使用上面的'dbfilename'配置指令指定文件名
#
# The Append Only File will also be created inside this directory.
# 仅追加文件也将在此目录中创建
#
# Note that you must specify a directory here, not a file name.
# 注意，这里必须指定目录，而不是文件名
dir usr/redis/backup

2、AOF持久化

AOF(Append Only File)，Redis文件追加持久化，AOF持久化则是将Redis执行的每次写命令记录到单独的日志文件中，即【appendonly.aof】文件。需要注意的是，要将【appendonly】设置为【yes】。只针对数据修改，读取不记录。跟RDB相比，AOF只允许追加文件，不允许修改文件。AOF会将每条数据更改的命令记录下来，当文件大小达到某个设定的阈值后，利用重写机制重写日志文件，保留针对某个数据的最后一条指令。

文件不压缩，文件大，恢复速度慢。

文件大，体现在AOF会将每条数据的更改进行记录，当操作频繁后，文件会越来越大。

触发AOF的方式：

在【redis.conf】配置文件中，开启相关配置

appendonly yes

# The name of the append only file (default: "appendonly.aof")
# 追加到哪个文件的名称
appendfilename "appendonly.aof"

持久化频率有三个参数：

# 每个写命令都同步，新的命令追加到aof文件，慢但安全
appendfsync always
# 每秒同步一次，丢失概率小
appendfsync everysec
# 从不主动同步，交给操作系统决定何时同步
appendfsync no

重写的阈值设置

# 百分比，AOF文件的增长率达到
auto-aof-rewrite-percentage 100
# AOF文件大小达到多少
auto-aof-rewrite-min-size 64mb
# 或者客户端输入bgrewriteaof

AOF_BUF缓冲区

使用AOF进行同步时，还存在一个缓冲区，用来记录Redis的一些操作命令，所以AOF也不是实时写入到aof文件，取决于采用哪种同步方式。

flushAppendOnlyFile函数

• Redis的服务器进程就是一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数
• 因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中的内容写入和保存到AOF文件里面

AOF重写

跟【RDB】的​​bgsave​​​命令类似，【AOF】也可以通过客户端输入​​bgrewriteaof​​完成重写。

当满足设置的条件时，会触发【AOF】重写，【Redis】会扫描整个实例的数据，重新生成一个【AOF】文件来完成一些多余命令的过滤(针对Key对应的Value的多次重复操作，只保留最后一次)，从而削减了文件大小。

所以AOF重写机制，就是重新生成一个AOF日志文件，只将当前有效并存在的数据转义成符合AOF日志格式的记录，然后依次写入该日志文件，最后刷入磁盘。这些操作都是在子进程中进行的，不会阻塞主进程，而导致无法处理新的请求。

AOF文件数据恢复

AOF记录的是每次数据的操作命令，所以在恢复时，是通过伪客户端来进行实现的。对aof文件进行读取，并对每条命令进行执行即可完成数据恢复。

RDB与AOF执行方式上的区别

RDB与AOF的优缺点

3、混合持久化 / RDB_AOF的方式

混合持久化是【RDB】与【AOF】两种方式的混合模式，在【Redis4.0】后新增的一种方式。将两者的优点进行整合，混合方式采用【AOF】的方式记录数据的变化，采用【RDB】的方式进行二进制文件存储。也就是在写入的时候先把数据以【RDB】的形式写入文件的开头，再将后续的写命令以【AOF】的格式追加到文件中。本质上是一种特殊的AOF方式，呼玛河持久化方式同样支持重写。

​

前提

开启混合持久化方式，必须线开启AOF持久化方式。

混合持久化配置

# 混合持久化开关
aof-use-rdb-preamble yes

混合持久化开启，系统根据策略触发 AOF ​​rewrite​​时，​​fork​​ 一个子线程将内存数据以 RDB 二进制格式写入 AOF 文件头部，那些在重写操作执行之后执行的 redis 命令，则以 AOF 持久化的方式追加到 AOF 文件的末尾。

触发RDB_AOF的方式

因为是特殊的AOF，所以触发时采用的是AOF的配置方式。

RDB_AOF重写

当AOF文件在重写时，会将之前的操作命令转化为RESP命令写入AOF文件，新增的命令按照原有的格式存储，两种格式进行存储。

RDB_AOF文件数据恢复

在数据恢复时，会先加载【RDB】的内容，然后再重放增量【AOF】格式命令。这样就避免了【AOF】持久化时的全量加载，从而使加载速率得到大幅提升。

• AOF 文件开头是 RDB 的格式, 先加载 RDB 内容再加载剩余的 AOF。
• AOF 文件开头不是 RDB 的格式，直接以 AOF 格式加载整个文件。

4、Redis备份策略

1. 写crontab定时调度脚本，每小时都进行复制一份【RDB】或者【AOF】到其它目录，仅保留近48小时的备份
2. 每天保留一份当日的数据到一个目录中去，保留一个月的备份
3. 每次备份时都将时间较长的备份删除掉
4. 每天可以将当前服务器的备份复制到其它机器上，做灾备。
5. 定期将持久化文件同步至云存储中