RDB
RDB Redis Database Backup file Redis数据备份文件,也可称为Redis数据快照。目的就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启,从磁盘中读取快照文件恢复内存数据。
save命令
由Redis主进程执行,执行期间阻塞式其他的命令,用于关闭前执行
Redis停机时会执行一次save RDB
bgsave命令
使用子进程异步执行持久化,可以避免主进程受到影响,适用于redis运行中持久化
配置
在redis.conf中配置触发条件
# 300秒内至少有一个key被修改 执行bgsave , save " " 标识禁用RDB
save 300 1
# 是否压缩,建议不开启压缩,开启后会浪费cpu资源,硬盘比较廉价可以空间换事件
rdbcompression yes
# rdb文件的名称
dbfilename dump.rdb
# 文件保存的目录
dir ./
bgsave原理
bgsave命令会fork主进程到子进程,子进程会共享主进程的内存数据。完成fork后读取内存数据写入RDB文件。
fork采用了copyOnWrite技术
- 主进程读操作时,访问共享内存
- 主进程写操作时,会从共享内存中拷贝一份,再执行写操作
fork后会将共享内存置为只读,此时如果主进程需要修改内存则会复制共享内存再去修改
AOF
AOF全称为 Append Only File 。Redis处理的每一个写命令都会记录在AOF文件中,可以看作是Redis执行命令的日志文件。
配置
在默认配置中AOF时被关闭的,需要修改redis.conf文件开启AOF
# 是否开启AOF功能,默认时no
appendonly yes
#AOF的文件名称
appendfilename "appendonly.aof
AOF的记录频率配置
# 执行写命令以后立即记录到AOF文件
appendfsync always
# 执行写命令后,先将记录存入AOF缓冲区,每隔一秒钟将缓冲区的数据写到AOF文件,也是AOF的默认配置
appendfsync everysec
# 执行写命令后,先将记录存入AOF缓冲区,由操作系统决定何时将数据写入磁盘,写入周期不可控一般不使用
appendfsync no
配置值 | 刷盘时机 | 优点 | 缺点 |
---|---|---|---|
always | 同步刷盘 | 可靠性高,几乎不丢失数据 | 性能影响大 |
everysec | 每秒刷盘 | 性能适中 | 最多丢失一秒的数据 |
no | 操作系统空值 | 性能最好 | 可靠性差,又可能丢失大量的数据 |
bgrewriteaof命令 aof文件瘦身
用途
因为aof文件记录了redis执行的命令,所以会占用更大的空间。在重复对一个key修改时只有最新一次修改的值才有意义,曾经的修改可以舍弃。这时使用bgrewriteaof命令可以优化aof文件的大小。
自动触发rewriteaof的配置
# AOF文件相比上次文件,增长超过的百分比会触发bgrewriteaof
auto-aof-rewrite-percentage 100
# AOF文件体积达到一定大小后触发bgrewriteaof
auto-aof-rewrite-min-size- 64mb
同时开启AOF和RDB会怎样
打开官方文档(配置文件中也有相关说明)https://redis.io/docs/manual/persistence/
如果同时开启AOF和RDB 在启动Redis时会优先加载AOF,因为AOF更全一些。
AOF和RDB的对比
对比项 | RDB | AOF |
---|---|---|
持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
数据完整性 | 不完整,两次备份之间断电会丢数据 | 记录每一次执行的命令 |
文件大小 | 可以配置压缩,文件体积较小 | 记录执行的命令,文件体积大 ,可以rewrite但体积还是较大 |
宕机恢复速度 | 很快 | 慢 |
同时开启AOF和RDB数据恢复优先级 | 低,数据完整性不如AOF | 高,因为数据完整性比RDB高 |
资源的占用 | 高,大量的cpu和内存的消耗 | 低,主要是磁盘的io占用,但AOF重写时会占用大量的资源 |
使用场景 | 可以容忍数分钟的数据丢失,需要更快的 启动速度 | 对数据的安全性要求较高 |
评论区