redis持久化方式
一、RDB
- redis database:快照,某一时刻将内存中的数据,写入磁盘中生成1个dump.rdb文件
- RDB的触发方式:
- 手动触发:save(阻塞主进程,阻塞其它指令,保证数据一致性)、bgsave(fork 子进程,可能不是最新的数据,但是不阻塞主进程和其它指令)
- 自动触发:shutdown(服务正常关闭,会将内存中的数据写入rdb文件)、flushall(清空数据指令,会保存1个空的rdb文件)、配置触发(save配置项)
- RDB的优缺点:
- 优点:备份、恢复速度快,主进程指令操作不需要跟磁盘有任何交互
- 缺点:可能存在数据丢失,fork 子进程可能影响cpu性能
save 900 1 900s检查1次,如果有1个key发生了变化,则记录rdb
save 300 10 300s检查1次,如果有10个key发生了变化,则记录rdb
save 60 1000 60s检查1次,如果有1000个key发生了变化,则记录rdb
根据上面的配置我们知道,如果在rdb之前redis宕机则数据会丢失
二、AOF
-
apend only file:追加文件,默认关闭,保存的是除get之外的1条条指令,如果开启会使用aof恢复数据
- appendfsync always:每条指令都跟磁盘交互,最安全,但是最慢
- appendfsync evrysec: 每秒异步写入aof文件,可能丢失1s钟的数据,性能适中
- apendfsync no:交给操作系统处理,linux默认30s,性能最好,但是最不安全
-
aof重写:因为aof是追加写,所以aof文件随着时间推移会越来越大,导致加载数据越来越慢,所以需要重写(把无效的指令删除掉)。
- 怎么重写:只要拿到当前redis中最新的数据以rdb保存,写入aof文件,之后的指令追加写入至aof中即可,aof-use-rdb-preamble yes 默认开启使用RDB重写aof;
- 重写时机:当aof文件达到64m时(auto-aof-rewrite-min-size 64mb默认),触发重写,如果经过第1次重写之后aof文件的大小被压缩至40m,那么下次触发aof重写的时机是aof文件达到80m。auto-aof-rewrite-percentage 100 下次重写必须是上次重写后大小的两倍;
- 重写流程:当触发aof重写时,新起一个子进程,将当前redis中的最新数据生成一个rdb文件,写入临时的aof文件中,在重写过程中的新指令,继续写入老的aof文件中,当临时aof文件写成功之后,再追加新指令至临时的aof文件,最后将临时的aof文件替换老的aof文件。
-
aof的优缺点:
- 优点:安全性高、可读性高(根据配置可以保证最多丢失最后1条指令的数据 appendfsync always),如果失败能修复
- 缺点:恢复很慢,但是redis4.0之后性能与rdb相差无几,并发量高的时候占用内存,在aof重写的时候,新指令要经过两次IO操作