redis持久化:RDB和AOF

目录

RDB 持久化

1、修改配置文件：redis.conf

2、RDB模式自动触发保存快照

3、RDB模式手动触发保存快照

4、RDB的优缺点

AOF持久化

1、AOF持久化工作流程

2、修改配置文件开启AOF

3、AOF优缺点

4、AOF的重写机制原理

RDB+AOF混合模式

---

redis持久化有两种方式：RDB和AOF

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

RDB 持久化

redis关于持久化配置文件的变化：

redis6.0.16以下

save 900 1:每隔900s(15min)，如果有超过1个key 发生了变化，就写一份新的RDB文件

save 300 10:每隔300s(5min)，如果有超过10 个key发生了变化，就写一份新的 RDB文件

save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件

redis6.2以上

save 3600 1:每隔3600s(1小时)，如果有超过1个key 发生了变化，就写一份新的RDB文件

save 300 10:每隔300s(5min)，如果有超过100个key发生了变化，就写一份新的 RDB文件

save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件

这里使用的是docker容器中安装的redis

1、修改配置文件：redis.conf

快照文件名，建议加上端口号，多个redis容器好区分

2、RDB模式自动触发保存快照

save可以修改保存时间：5秒中2次修改就会触发快照

重新启动容器

docker restart redis

 进入容器查看是否配置成功

docker exec -it redis bash  #进入容器
redis-cli     #redis客户端

 查看快照文件目录：config get dir

/data# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"
127.0.0.1:6379> config get dir
1) "dir"
2) "/data"

测试：

测试前
[root@localhost data]# ll
总用量 4
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb


127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK

测试后
[root@localhost data]# ll
总用量 8
-rw-------. 1 polkitd input 107 11月 22 21:20 dump3679.rdb
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb

总结：5秒内修改2次或2次修改大于5秒都会触发，

redis重启就会读取快照恢复，执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义

3、RDB模式手动触发保存快照

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

save：在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用

BGSAVE(默认)：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，触发方式会fork一个子进程由子进程复制持久化过程

lastsave可以查看最后一次的时间戳

4、RDB的优缺点

RDB的优点

1、适合大规模的数据恢复

2、按照业务定时备份
3、对数据完整性和一致性要求不高
4、RDB 文件在内存中的加载速度要比AOF快得多

RDB的缺点

1、在一定间隔时间做一次备份，所以如果redis意外宕机的话,就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失

2、内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
3、RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一俯，大致2倍的膨胀性，需要考虑

修复RDB文件

cd /usr/local/bin

进入bin目录找到：redis-check-rdb 命令，指定rdb文件

redis-check-rdb /usr/local/redis/data/dump6379.rdb 

 

 禁用RDB快照，把save前面的注释去掉，写个空字符串

 RDB配置参数，使用默认即可

 

AOF持久化

默认情况下，redis是没有开启AOF(append only file)的。

开启AOF功能需要设置配置: appendonly yes

1、AOF持久化工作流程

1、Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2、在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3、AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4、随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。

AOF缓冲区三种写回策略

Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。

everysec：每秒写回，每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。

no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

2、修改配置文件开启AOF

开启AOF：appendonly改为yes

策略为默认

文件保存路径

redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置

redis7：相对于redis6会多建一个appendonlydir文件路径

文件名称

redis6只有一个文件

redis7由Multi Part AOF的设计变成3个文件：base基本文件，incr增量文件，manifest清单文件

示例：开启AOF，写入数据

发现多一个文件夹

 AOF异常文件修复

进入bin目录：cd /usr/local/bin

然后进入持久化文件，输入命令

redis-check-aof --fix appendonly.aof.1.incr.aof

"AOF is valid" 表明 AOF 文件是有效的，没有发现任何问题。

3、AOF优缺点

AOF优点：更好的保护数据不丢失、性能高、可做紧急恢复。

AOF缺点：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同。

由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

4、AOF的重写机制原理

1、在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2、与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3、当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

4、当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中。

5、重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

RDB+AOF混合模式

当RDB，AOF都存在时，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文供保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。

那么只使用AOF呢?
建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

开启混合模式：在redis.conf中redis默认开启