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文件

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

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

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

修改保存时间：5秒中两次修改

重新启动容器

docker restart redis

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

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

查看快照文件目录

/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文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。