Redis持久化存储总结与备份

Redis的读写性能俱佳，但由于是内存数据库，如果没有提前备份，Redis数据是掉电即失的。好在Redis提供了两种方式进行持久化：1、RDB持久化 2、AOF持久化

原理

RDB持久化

将Redis在内存中的数据定时dump到磁盘上，实际操作过程是fork一个子进程，先将数据写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储

打印rdb文件

root@pa6:/var/lib/redis# od -c dump.rdb
0000000   R   E   D   I   S   0   0   0   6 376  \0  \0 003   k   e   y
0000020 301 177   # 377   ]   } 362 366 313 362   n 020
0000034

AOF持久化

AOF持久化：将Redis的操作日志以文件追加的方式写入文件，只记录写、删除操作，查询操作不会记录（类似于MySQL的Binlog日志）

自动间隔性保存

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令

用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令 举个例子，如果我们向服务器提供以下配置

vim redis.conf

save 900 1
save 300 10
save 60 10000

那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行 服务器在900秒之内，对数据库进行了至少1次修改

服务器在300秒之内，对数据库进行了至少10次修改

服务器在60秒之内，对数据库进行了至少10000次修改。

RDB持久化实现

Redis数据库Redis是一个字典结构的存储服务器，一个Redis实例提供了多个用来存储数据的容器， 客户端可以指定将数据存储在哪个容器中（类似于MySQL中的数据库）。

Redis默认支持16个数据库，可以通redis.conf配置文件修改数据库个数，客户端与Redis建立连接之后默认选择0号数据库

备份

• 自动开启RDB持久化

修改配置文件

# 默认redis会开启RDB持久化
备份文件的名称
dbfilename dump.rdb

备份文件存放路径
dir /var/lib/redis   

• 当前数据库备份

Redis的SAVE命令和BGSAVE命令用于将当前数据库备份

127.0.0.1:6379> save  #数据量大的话cpu会爆炸
OK

127.0.0.1:6379> bgsave    #建议使用这个
Background saving started

SAVE和BGSAVE命令的区别在于：SAVE命令是阻塞主进程，save操作完成之后，主进程才开始工作，客户端可以连接；BGSAVE命令是fork一个专门save的子进程，此操作不会影响主进程

注：SAVE只是将当前的数据库备份，备份文件名默认为dump.rdb,可通过配置文件修改备份文件名 dbfilename xxx.rdb（发现一个问题：如果要对多个数据库进行备份，那么最终只能备份最后一个数据库，因为dump.rdb文件会相互覆盖）

恢复

将备份的RDB文件，cp到要恢复的redis指定目录，重启Redis即可自动读取持久化文件，自动恢复数据

• 备份的RDB文件： 通过命令redis 127.0.0.1:6379> CONFIG GET dir查看执行SAVE命令之后，redis默认存放备份文件的目录；通过命令redis 127.0.0.1:6379> CONFIG GET dbfilename查看备份RDB文件的文件名称；

root@pa6:~# redis-cli
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/var/lib/redis"
127.0.0.1:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "dump.rdb"

AOF持久化实现

备份

备份过程分以下三个阶段

• 命令传播： Redis将执行完的命令、命令参数等信息发送到AOF程序
• 缓存追加： AOF程序将接收到的命令内容追加到服务器的AOF缓存中
• 文件写入和保存： AOF缓存中的内容被写入到AOF文件末尾，如果满足AOF保存条件，写入的内容会真正保存到磁盘中

进行AOF备份

• 首先开启AOF功能

修改配置文件

#此选项为aof功能的开关，默认为“no”，通过“yes”来开启aof功能
appendonly yes  

#指定aof文件名称
appendfilename appendonly.aof

#备份文件存放路径（此参数同样适用于指定RDB备份文件存放路径）
dir /var/lib/redis

设置保存模式（配置文件）

AOF有3种方式将操作命令存入AOF文件

1. appendfsync no 不保存

只执行WHRITE操作，SAVE操作会被略过，只有在Redis被关闭、AOF功能被关闭、系统的写缓存被刷新（如缓存已被写满）这三种情况，SAVE操作会被执行，但是这三种情况都会引起Redis主进程阻塞

2. appendfsync everysec 每秒钟保存一次

这种模式中，SAVE原则上每隔一秒钟就会执行一次，具体的执行周期和文件写入、保存时，Redis所处的状态有关，此模式下SAVE操作由后台子线程调用，不会引起服务器主进程的阻塞

3. appendfsync always 每执行一个命令保存一次 在这种模式下，每执行一个命令，WRITE和SAVE都会被执行，且SAVE操作会阻塞主进程

设置好AOF写入的模式之后，只要达到写入条件（比如一秒钟、执行一个命令），就会自动在指定路径下生成AOF文件，并往里面记录操作命令

AOF文件重写

AOF文件通过同步Redis服务器所执行的命令，实现对数据库状态的记录。有些被频繁操作的键，对它们所调用的命令可能有成百上千、甚至上万条，这样很容易出现AOF文件体积急速膨胀，对Redis甚至整个系统造成影响。

• AOF重写实现原理

如果服务器对键list执行以下四条命令：

RPUSH list 1 2 3 4      // [1, 2, 3, 4]

RPOP list               // [1, 2, 3]

LPOP list               // [2, 3]

LPUSH list 1            // [1, 2, 3]

那么当前列表键list在数据库的值就是[1,2,3]，如果我们要保存这个列表的当前状态，并且尽可能地减少使用命令数，最简单的方法是直接读取list键在数据库的当前值，然后用一条RPUSH list 1 2 3命令代替前面四条命令。

根据键的类型，使用适当的写入命令来重现键的当前值，这就是AOF重写的实现原理

• AOF后台重写

子程序处理： AOF重写程序，会阻塞主进程，作为一种辅助性的维护手段，Redis不希望AOF重写造成服务器无法处理请求，所以Redis会将重写程序放到子进程执行。

AOF重写缓存： 不过，使用子进程也有一个问题需要解决：子进程在进行AOF重写期间，主进程还在继续处理命令，新的数据更新不能同步到重写后的AOF文件中。为了解决这个问题，Redis增加了一个AOF重写缓存，这个缓存在fork出子进程之后开始启用，重写期间的写操作，除了会将写命令追加到现有的AOF文件之外，还会追加到这个缓存中。子进程完成重写操作之后，它会向父进程发送一个完成信号，父进程接到完成信号之后，会调用一个信号函数，将AOF重写缓存中的内容写入新的AOF文件中。

性能影响： 在整个AOF后台重写的过程中，只有最后的写入缓存会造成主进程的阻塞，其他时候，AOF后台重写都不会阻塞主进程。

• 进行后台重写：

1. 系统自动后台重写（需满足一定触发条件）：

i 没有正在执行的BGSAVE和BGREWRITEAOF命令

ii 当前AOF文件大小大于aof_rewrite_min_size

iii AOF文件大小和最后一次重写大小的比率大于aof_rewrite_perc

2. 手动后台重写：

通过BGREWRITEAOF手动重写

恢复

和RDB恢复是一样的操作，将备份的AOF文件，放在指定目录，重启Redis即可恢复数据（具体可参照上文的RDB恢复数据）

ps: 当指定目录同时有RDB文件和AOF文件时，还原数据时AOF文件的优先级是高于RDB文件的，所以优先通过AOF文件还原数据

二者优缺点

RDB持久化

优点：

• RDB方式备份，整个Redis数据库最终备份成一个文件，这对于文件备份而言是完美的（方便管理、还原、压缩、转储）
• 对服务进程影响最小，唯一需要做的是fork出子进程，之后所有的持久化工作交由子进程处理
• 相比于AOF机制，如果数据量比较大，RDB的启动效率会更高（记录的是源数据，而非数据操作）

缺点：

• 数据的可用性得不到太大的保障，如果在定时持久化之前出现宕机现象，此前没来得及写入磁盘的数据都将丢失
• 如果数据量较大，fork子进程的操作可能会使服务短暂停止（通常是几百毫秒）

AOF持久化

优点：

• 拥有更高的数据可用性，数据持久化最完整
• 日志文件采用append模式，即使在写入过程中出现宕机现象，也不会破坏日志文件之前已经存在的内容
• 提供rewrite机制，当日志过大时，Redis以append模式不断将修改的日志写入老的磁盘文件，同时Redis还会创建一个新的文件用于记录此期间有哪些命令被执行

缺点：

• 对于相同数量的数据，AOF文件通常大于RDB文件，RDB文件在恢复大数据集的速度比AOF恢复的更快（RDB省去了执行的步骤，直接导入源数据）

总结

RDB持久化，性能更好（所有操作均由子进程处理，主进程不进行任何IO操作），数据一致性一般。

AOF持久化，数据一致性更好，性能一般（记录操作日志，写入日志和执行日志恢复数据的时间都比RDB更长）。

Redis 恢复的机制

• 如果只配置 AOF ，重启时加载 AOF 文件恢复数据；
• 如果同时配置了 RDB 和 AOF ，启动是只加载 AOF 文件恢复数据；
• 如果只配置 RDB，启动是将加载 dump 文件恢复数据。

备份脚本

demo

#!/bin/bash
# 避免造成雪崩
set -e
# bak 目录
BACKUPDIR=/data/redis/backup
#PASSWD='redis密码'
#DATADIR=`/usr/local/bin/redis-cli -p 端口 -a "$PASSWD" config get dir|grep -Ev 'dir|grep'`
# 获取redis-cli 二进制文件
REDIS_CMD=$(which redis-cli)
DATADIR=`$REDIS_CMD  config get dir|grep -Ev 'dir|grep'`
DATE=`date +'%Y-%m-%d-%H-%M'`
BACKUPDIR_DATE=$BACKUPDIR_$DATE

if [ ! -d $BACKUPDIR ];then
        mkdir -p $BACKUPDIR \
        || echo "can't make dir !!!" \
        && exit 1
fi
#以日期分类
mkdir -p $BACKUPDIR/$BACKUPDIR_DATE
$REDIS_CMD  bgsave
sleep 3
cp -rf $DATADIR/* $BACKUPDIR/$BACKUPDIR_DATE