目录
Redis数据持久化机制有两种:RDB、AOF
一、RDB
Redis Database Backup file(Redis数据备份文件),也叫Redis数据快照,把内存中的所有数据记录到磁盘中,redis重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前运行目录。
- 执行save,Redis主进程来执行RDB,会阻塞所有命令。
- 执行bsave,返回Background saving started 后台保存,异步执行,有另外的线程单独执行。
1.两种场景
1.1主动停机
会自动执行sava
当Redis客户端停机会打印:Saving the final RDB snapshot before exting。 保存完成会有“DB saved on disk”提示信息。
1.2突然宕机
Redis 内部有出发RDB的机制,可以在redis.conf文件中找到,格式:
save 900 1
save 300 100
save 60 10000
save 900 1 表示在900s内至少有1个key被修改,则执行bgsave,如果是save “ ” 则表示禁用RDB。
RDB的其他配置在redis.conf文件中设置:
是否压缩,将以不开启,压缩也会消耗cpu
rdbconpression yes
RDB文件名称
dbfilename dump.rdb
文件保存的路径目录
dir ./
2.bgsave原理
bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据,完成fork后读取内存数据并写入RDB文件,fork采用的是copy-on-write技术:
当主进程执行读操作时,访问共享内存;
当主进程进行写操作时,则会拷贝一份数据,进行写操作。
fork主进程得到一个子进程,共享内存空间
子进程读取内存数据并写入新的RDB文件(异步)
用新RDB文件替换旧的RDB文件
3.RDB缺点
RDB执行时间长,两次RDB之间写入数据有丢失的风险,fork子进程,压缩写出RDB文件都比较耗时。
二、AOF
Append Only File(追加文件),Redis处理的每一个写命令都会记录在AOF文件里,可看做是命令日志文件。
AOF默认是关闭的,需要修改redis.conf配置文件开启AOF:
是否开启AOF功能,默认关闭 no
appendonly yes
AOF文件名称
appendfilename “appendonly.aof”
AOF的命令记录的频率通过redis.conf文件配置:
表示每执行一次命令,立即记录到AOF文件
appendfsync always
写命令执行完先放AOF缓冲区,然后每个1秒将缓冲区数据写到AOF文件,是默认方案
appendsync everysec
写命令执行完先放AOF缓冲区,有操作系统决定何时将缓冲区内容写回磁盘。
appendfsync no
配置完成后,修改数据,停掉客户端:
Calling fsync() on the AOF file
重开客户端:DB loaded from append only file :0.000 seconds
1.三种记录频率比较
配置项 | 刷盘时机 | 优点 | 缺点 |
always | 同步刷盘 | 可靠性高,几乎不丢数据 | 性能影响大 |
everysec | 每秒刷盘 | 性能适中 | 最多丢失1s数据 |
no | 操作系统控制 | 性能最好 | 可靠性较差,可能丢失大量数据 |
三、RDB 和 AOF 比较
RDB | AOF | |
持久化方式 | 定时对整个内存做快照 | 记录每次执行的命令 |
数据完整性 | 不完整,两次备份之间会丢失 | 相对完整,取决刷盘策略 |
文件大小 | 会有压缩,文件体积小 | 记录命令,文件体积大 |
宕机恢复速度 | 快 | 慢 |
数据恢复优先级 | 低,数据完整性比AOF较差 | 高,数据完成性高 |
系统资源占用 | 高,大量cpu和内存消耗 | 低,主要是磁盘IO |
使用场景 | 可以容忍数分钟数据丢失,追求更快的启动速度。 | 对数据完全性要求较高 |