1.什么叫持久化
官方介绍:Redis中的持久性是指数据写入磁盘,并在重启或系统故障时恢复数据的能力。Redis提供了四种持久化选项:RDB(Redis数据库)快照和AOF(仅追加文件)日志、RDB+AOF以及无持久化,纯缓存模式。
简而言之,Redis的持久性,是本身具有的一种特性,是为了将Redis上的数据以及状态,通过持久化机制,存储在硬盘;当Redis出现意外情况,用于恢复Redis数据;
.为啥需要持久化呢?
因为,当我们关闭redis线程,或者关闭计算机后,redis上的数据会被操作系统在内存上清除,所以,redis如果没有做持久化,在重启redis后,数据会丢失
2.持久化有哪些方式
通过官网可知悉,目前Redis支持最主要的两种持久化机制:RDB、AOF
RDB(Redis DataBase):Redis默认持久化模式
官方介绍:RDB 持久性按指定的时间间隔执行数据集的时间点快照。
也就是说,在指定时间间隔内将内存中的数据集快照(Snapshort内存快照)写入磁盘,然后在恢复的时候,再将硬盘中的快照文件直接读回内存里
那么,快照是什么?
快照:是一个二进制文件,包含了某个时间点Redis中的所有数据(百度得知)
其实这种实现形式,类似照片记录效果的方式,就是把某一时刻的数据和状态以文件的形式写到磁盘上,也就是快照;这个快照文件就称为RDB文件(dump.rdb);
AOF(Append Only File)
官方介绍:AOF 持久性会记录服务器接收的每个写入操作。然后,可以在服务器启动时再次重播这些操作,从而重建原始数据集。使用与 Redis 协议本身相同的格式记录命令
那也就是说,AOF会以日志的形式记录每个写入操作,将Redis执行过的所有写指令记录下来(读操作不记录),特别注意,AOF持久化模式的时候,只能追加文件不能改写文件(AOF保存的是appendonly.aof文件);然后,redis在重启时,通过读取aof文件内容,将写指令,重新执行一遍,从而实现数据的恢复工作;
另外两种:
一种是,完全不需要持久性,禁用所有的持久性,当然,此时,redis是当作缓存使用的,所有也叫,纯缓存模式;
另一种,就是RDB和AOF混用,RDB镜像做全量持久化,AOF做增量持久化;先使用RDB进行快照存储,然后使用AOF持久化记录所有的写操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录。但记住,在同时开启rdb和aof持久化的时候,重启是只会加载aof的文件,不会加载rdb文件(AOF更新频率更快,数据更加完整,所以如果AOF和RDB同时存在的时候,Redis会优先使用从AOF文件来还原数据库状态,如果AOF关闭状态时,则从RDB中恢复)
3.持久化操作
RDB持久化,触发方式:通过修改redis.conf里的配置save <seconds> <changes>,当在规定时间内完成操作次数,就会生成一笔RDB文件
自动触发:
Redis6.0.16以下版本
Redis6.2以及Redis-7.0.0之后的版本
除此之外,还需要更改dump文件保存路径(保险操作,备份数据与redis不在一台机器上,以防止,机器损坏,备份数据获取不到),还可以修改dump文件名称
手动触发:Redis提供了两个命令来⽣成RDB⽂件,分别是save和bgsave
save:
在主进程执行时会阻塞当前redis服务器,直到save操作执行完成,在这之前,redis不能处理其他的事情
bgsave(默认):
Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程,这个操作是子进程在后台完成的,这就允许主进程可以同时修改数据
那些情况会触发RDB快照:
- 配置快照配置,自动触发
- 手动触发
- 执行flushall/flushdb命令也会产生dump.rdb文件,但是文件为空,没有意义
- 执行shutdown,且未配置AOF持久化
- 主从复制,主节点自动触发
AOF启动操作:
1.开启AOF功能设置配置:appendonly yes
2.配置写回策略
AOF持久化工作流程
AOF写回策略设置
AOF缓存区的三种写回策略
3.配置aof文件-保存路径,
redis7之前,redis6,AOF文件保存位置与RDB文件保存位置一致,都是通过redis.conf配置文件的dir配置
redis7之后,在原有基础上添加 appenddirname 配置,形成,dir + appenddirname 的形式
4.配置aof文件-保存文件名称
redis6,只有一个文件,文件名为appendonly.aof
redis7,由三部分组成:base基本文件;incr增量文件;manifest清单文件
AOF的重写操作:
官方介绍
一句话:启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
从 Redis 7.0.0 开始,当计划重写 AOF 时,Redis 父进程会打开一个新的增量 AOF 文件以继续写入。 子进程执行重写逻辑并生成新的基础 AOF。 Redis 将使用临时清单文件来跟踪新生成的基础文件和增量文件。 当它们准备就绪时,Redis 将执行原子替换操作,以使此临时清单文件生效。 为了避免在反复失败和重试 AOF 重写的情况下创建许多增量文件的问题, Redis 引入了 AOF 重写限制机制,以确保以越来越慢的速度重试失败的 AOF 重写。
触发机制
1.自动触发;
注意 ,同时满足,且的关系才会触发
1 根据上次重写后的aof大小,判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小
2,手动触发:
客户端向服务器发送bgrewriteaof命令
重写原理
4.持久化后如何恢复
RDB:将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
AOF:
1.正常恢复,将生成的AOF文件放在指定的目录下,启动服务即可
2.异常恢复:
redis-check-aof --fix 进行修复
5.持久化如何禁用
RDB:
1.redis -cli configset save
2.save ""
AOF:配置redis.conf配置文件,将appendonly 设置成no
6.持久化的优劣
RDB:
AOF
总结,RDB,在大规模数据恢复更具价值,AOF能更好的确保数据不丢失,性能高,可做紧急恢复;缺点,RDB相较于AOF更容易丢失数据,并且RDB依赖于主进程的fork,在大数据集中,会导致服务请求的瞬间延迟;AOF,文件比RDB文件大,AOF恢复速度慢于RDB
7.持久化如何选择
根据AOF与RDB的优点酌情选择
,也可以选择第三种方式:RDB+AOF的混合模式,但是要注意