Redis 持久化
现在大家都习惯与用Redis作为缓存系统,并且在其中放入常用的热点数据,从而减少直接对数据库访问的操作。
Redis 持久化就是将 Redis 内存数据永久存储到磁盘中的操作
Redis提供的两种持久化方式
-
RDB (Redis DataBase)
在不同间隔时间点将 Redis 内存数据生成快照并存储到磁盘中(存储数据)
-
AOF(Append Only File)
记录Redis执行过的所有写指令(存储指令)
RDB(Redis DataBase)
是指Redis将某一时刻的数据记录生成快照,存储到磁盘中
上述图可以看出,Redis在进行持久化数据时,会先将内存数据写入临时文件中,然后再将临时文件保存入内盘(替换原有的持久化文件)
上述操作是以周期性进行的,也就是说:过多长时间,操作多少数据,他就会记录一次。
RDB主要有以下周期
这样可以有效地避免:如果Redis直接将数据写入硬盘中,首先要清除原有的数据,然后在写入新的数据。若是发生系统故障或者断电,就会导致新旧数据都会损失。
并且这种方式,RDB会直接创建一个子进程来进行持久化,主进程不进行任何的读写操作
RDB持久化的优点
- 体积更小:相同数据量的RDB文件比AOF更小
- 恢复更快:只是进行数据的记录,不用进行数据操作
- 性能更高:父进程在保存 RDB 文件时只需要 fork() 一个子进程,无需父进程的进行其他 I、O操作,从而保证 Redis 服务器的性能
RDB持久化的缺点
- 数据有丢失的风险: Redis 服务器出故障时,使用RDB持久化可能丢失数据
- 耐久性差:数据量很大时RDB比AOF持久化更加消耗时间和CPU资源
使用场景:由于RDB这种方式持久化数据是不注重数据的完整性。若你需要大量数据的恢复,并且对数据的完整性要求不高,就可以使用RDB。
AOF(Append Only File)
AOF持久化,从英文名可以看出,只允许追加不允许改写文件的持久化
RDB记录的是数据。那么AOF记录的是数据的操作。
举个例子:授人与鱼不如授人与渔
RDB就是授的鱼(数据),AOF是授的渔(数据的操作)。
对于AOF的配置中,我们简单了解一下其级别即可:
我们重点学习的为AOF的重写原理
AOF文件的重写原理
为什么要进行AOF文件重写
首先我们知道AOF记录Redis执行过的所有写指令,这些记录统一记录到AOF文件中。但是随着写指令的增多,文件就会越来越大,文件太大就会对Redis服务器造成影响,并且还原AOF文件所需的时间也会越长。
为了解决AOF文件体积膨胀的问题,Redis提供AOF文件重写功能
先来看图:
解释一下:
首先我们看到AOF文件重写有两个进程:
- 主进程:用来接收新的写指令,并将其放入缓存区。
- 子进程:负责重写,分为以下几步
- 读取原本的AOF文件
- 分析原本文件和新的写指令,并将其压缩后放入一个临时AOF文件
- 将临时的文件写入内存中,代替原本AOF文件成为新的AOF文件
AOF支持化优缺点
AOF支持化优点
- 故障数据不丢失:可以设置 appendfsync 策略,一般默认是 everysec,也可以设置每次写入追加,所以即使服务故障宕机,也最多丢失1秒数据
- AOF 文件重写:当 AOF 文件大小到达一定程度的时候,后台会自动的去执行 AOF 文件重写,此过程不会影响主进程,重写完成后,新的写入将会写到新的 AOF 中,旧的就会被删除掉
AOF支持化缺点
- 性能相对较差:AOF 持久化操作模式决定会对 Redis 的性能有所损耗
- AOF 文件更大:尽管有 AOF 文件重写,但是随着 Redis 服务器写操作增多,AOF 文件依然会增大
- 恢复速度更慢:还原数据库状态是通过加载AOF文件内容,逐条执行记录的写操作,显然速度比RDB更慢
如何选择 Redis 持久化策略
官方的建议是两个同时使用,可以提供更可靠的持久化方案。但是AOF默认是关闭的。