Redis的持久化

Posted 2021-02-28 繁华乱世

简介：

Redis是一个缓存技术，也叫NoSQL数据库，既然是数据库，那么必然支持持久化操作，在redis中有两种持久化操作：

1.快照：一次全量备份，它是内存数据二进制序列化形式，在内存中比较节省空间。

2.AOF日志：连续增量备份，记录的是内存修改指令的记录文本，数据库重启需要加载AOF日志，进行指令重放的时候，会是一个很漫长的过程，因为执行AOF日志会将你曾经的命令再执行一次。所以一般会定期对AOF重写，也就是瘦身。

快照技术的实现：

原理：

Redis使用操作系统多进程机制来实现快照的持久化，redis在持久化时，会fork一个子进程，然后持久化的操作交给子进程完成，而父进程则继续处理客户端请求。在这个过程中，子进程能够看到的内存中的数据在子进程产生的一瞬间就固定下来了，类似于虚拟机的快照。

具体配置：

在Redis中，快照持久化的方式是默认开启的。在默认情况下会产生一个dump.db文件，这个文件就是存放备份文件的。当redis启动时，会自动加载.db文件，从文件中恢复数据

具体的配置在edis.conf中

# 表示快照的频率，第一个表示 900 秒内如果有一个键被修改，则进行快照
save 900 1
save 300 10
save 60 10000
# 快照执行出错后，是否继续处理客户端的写命令
stop-writes-on-bgsave-error yes
# 是否对快照文件进行压缩
rdbcompression yes
# 表示生成的快照文件名
dbfilename dump.rdb
# 表示生成的快照文件位置
dir ./

备份流程：

1.在redis运行中，我们可以向redis中发送一条save命令，但是save是一个阻塞命令，当redis收到save命令开始处理备份操作，在没有处理完成之前，将不再处理其他的请求，其他请求就会被挂起。因此redis中又提供了一个命令，用在专门处理备份。

2.可以使用bgsave来备份，bgsave会fock一个子进程去处理备份，不影响父进程处理客户端请求。

3.我么定义的备份规则，如果有满足，也会自动触发bgsave

4.当我们执行shutdown命令时，也会触发save命令，备份数据，然后关闭数据库。

5. 用 Redis 搭建主从复制时，在 从机连上主机之后，会自动发送一条 sync 同步命令，主机收到命令之后，首先执行 bgsave 对数据进行快照，然后才会给从机发送快照数据进行同步。

AOF技术的实现：

和快照不同，AOF持久化是将执行命令追加到aof文件的末尾，在恢复的时候，只需要把记录下来的命令执行一遍就可以了。

默认情况下，aof是没有开启的，需要手动开启：

# 开启 aof 配置
appendonly yes
# AOF 文件名
appendfilename "appendonly.aof"
# 备份的时机，下面的配置表示每秒钟备份一次
appendfsync everysec
# 表示 aof 文件在压缩时，是否还继续进行同步操作
no-appendfsync-on-rewrite no
# 表示当目前 aof 文件大小超过上一次重写时的 aof 文件大小的百分之多少的时候，再次进行重写
auto-aof-rewrite-percentage 100
# 如果之前没有重写过，则以启动时的 aof 大小为依据，同时要求 aof 文件至少要大于 64M
auto-aof-rewrite-min-size 64mb

同时为了避免快照备份的 影响，需要注释掉conf文件中的三条规则，就是三个save命令。

两种持久化操作如何选择：

如果是做缓存服务器,那持久化基本用不上

如果同时开启了两种持久化操作，当redis重启的时候，会优先载入AOF文件来恢复数据，因为AOF保存的数据集要比快照方式保存的数据集完整。

快照方式用于备份数据库，它在redis启动的时候，Fock出来的子进程会一瞬间备份所有数据，而AOF，是在aop文件的末尾追加操作命令，会一直变，所以备份起来不太方便。

快照的方式要比aof在重载的时候快上很多。一般redis集群中，在从机上快照，15分钟备份一次，也就是保留save 900 1，这条规则就可以了。

aof备份的时候，最坏的也就是丢失一秒的数据，但是启用aof备份会带来持续的io，因为要不停的读写操作命令。还有一个劣势就是在rewrite 重写的过程中，新数据写到新文件造成的阻塞是不可避免的。