Redis
有两种持久化方案:
RDB
持久化AOF
持久化RDB
持久化RDB
全称Redis Database Backup file
(Redis
数据备份文件),也被叫做Redis
数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis
实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB
文件,默认是保存在当前运行目录。
RDB
持久化在四种情况下会执行:
save
命令bgsave
命令Redis
停机时RDB
条件时1)save
命令
执行下面的命令,可以立即执行一次RDB
:
save
命令会导致主进程执行RDB
,这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。
2)bgsave
命令
下面的命令可以异步执行RDB
:
这个命令执行后会开启独立进程完成RDB
,主进程可以持续处理用户请求,不受影响。
3)停机时
Redis
停机时会执行一次save
命令,实现RDB
持久化。
4)触发RDB
条件
Redis
内部有触发RDB
的机制,可以在redis.conf
文件中找到,格式如下:
# 900秒内,如果至少有1个key被修改,则执行bgsave , 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB
的其它配置也可以在redis.conf
文件中设置:
# 是否压缩 ,建议不开启,压缩也会消耗cpu,磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
RDB
原理bgsave
开始时会fork
主进程得到子进程,子进程共享主进程的内存数据。完成fork
后读取内存数据并写入 RDB
文件。
fork
采用的是copy-on-write
技术:
RDB
方式bgsave
的基本流程?
fork
主进程得到一个子进程,共享内存空间RDB
文件RDB
文件替换旧的RDB
文件RDB
会在什么时候执行?save 60 1000
代表什么含义?
RDB
RDB
的缺点?
RDB
执行间隔时间长,两次RDB
之间写入数据有丢失的风险fork
子进程、压缩、写出RDB
文件都比较耗时AOF
持久化AOF
全称为Append Only File
(追加文件)。Redis
处理的每一个写命令都会记录在AOF
文件,可以看做是命令日志文件。
AOF
配置AOF
默认是关闭的,需要修改redis.conf
配置文件来开启AOF
:
# 是否开启AOF功能,默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF
的命令记录的频率也可以通过redis.conf
文件来配:
# 表示每执行一次写命令,立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区,然后表示每隔1秒将缓冲区数据写到AOF文件,是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
三种策略对比:
AOF
文件重写因为是记录命令,AOF
文件会比RDB
文件大的多。而且AOF
会记录对同一个key
的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof
命令,可以让AOF
文件执行重写功能,用最少的命令达到相同效果。
如图,AOF
原本有三个命令,但是set num 123 和 set num 666
都是对num
的操作,第二次会覆盖第一次的值,因此第一个命令记录下来没有意义。
所以重写命令后,AOF
文件内容就是:mset name jack num 666
Redis
也会在触发阈值时自动去重写AOF
文件。阈值也可以在redis.conf
中配置:
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
RDB
与AOF
对比RDB
和AOF
各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用。