redis一共提供了两种数据持久化的方式RDB和AOF。
RDB全称为Redis Database Backup file(数据备份文件),也被叫做Redis数据快照。简单来说就是将内存中的全部数据都记录到磁盘中,当redis发生宕机或是一些故障导致实例故障重启,此时就会从磁盘中读取快照文件,恢复数据。
Redis内部有触发RDB的机制,可以在redis.conf文件中找到,格式如下:
save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,Redis就会自动触发bgsave命令创建快照。
save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,Redis就会自动触发bgsave命令创建快照。
save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,Redis就会自动触发bgsave命令创建快照。
bgsave会fork主进程得到子进程(主要复制的是主线程中的页表:记录着虚拟地址与物理地址的映射关系)子进程共享主进程的内存数据,完成fork后读取内存数据并写入RDB文件。
其中fork采用的是copy on write技术:
AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件。
aof默认是关闭的,需要更改redis.conf文件来进行配置。
aof记录频率也可以通过redis.conf进行配置。
配置项 | 刷盘时机 | 优点 | 缺点 |
---|---|---|---|
Always | 同步刷盘 | 可靠性高,几乎不丢数据 | 性能影响大 |
everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒数据 |
no | 操作系统控制 | 性能最好 | 可靠性较差,可能丢失大量数据 |
因为aof是记录命令。aop文件要比rdb大的多,而且aof会对记录中的一个key进行多测更改操作,但是只有最后一次的更改才有意义。可以通过bgrewriteaof命令对aof文件进行重写,使其用最少的命令达到最优的效果。
Redis也可以在redis.conf中进行自动配置,当aop中的据在某段时间达到某个阈值就会自动进行重写。
他们在实际应用中各有其优缺点,在Redis6.0之后两个配合使用。
RDB | AOF | |
---|---|---|
持久化方式 | 定时对整个内存进行快照 | 记录每一次的执行命令 |
数据完整性 | 不完整,在定时快照期间数据会丢失 | 相对完整,取决于刷盘策略 |
文件大小 | 会有压缩,文件相对较小 | 记录命令所以文件很大 |
宕机恢复速度 | 快 | 慢 |
数据恢复优先级 | 低,因为完整度不比AOF | 高,完整度高 |
系统资源占用 | 高,其中fork等操作对内存和CPU会有一定的消耗 | 低,主要是硬盘的io操作,进行命令重写时会占用CPU资源 |
使用场景 | 可以容忍数分钟的数据丢失情况(偏向于高可用性) | 对数据安全性要求较高的情况(对数据一致性要求高) |
RDB和AOF两种数据持久化操作的区别有哪些?
rdb时一个快照文件,它是将redis的数据都存储在硬盘中,当redis故障宕机后,方便从快照文件中恢复数据。
aof时一个追加文件(类似于一个日志文件),他是用来记录对数据的写命令操作,当redis宕机时,会重修执行一遍这个文件,从而恢复数据。
这两种持久化操作哪个的恢复速度比较快呢?
引文RDB是一个二进制文件,在保存的时候体积比较小,所以他若是用它进行数据恢复,数据恢复速度很快,但是他数据的完整性不高,在快照期间会数据丢失。AOF虽然恢复的速度相较于RDB慢,但是由于它可以配置刷盘策略,从而他的数据完整性较高。