目录
两种持久化机制
RDB(Redis DataBase)快照
AOF(Append-Only File)仅追加文件
RDB
快照是最简单的Redis持久化模式,也就是生成某个时间点的数据集,生成RDB文件。
触发RDB的方式
手动触发
1. save命令:阻塞当前Redis服务器,直到RDB过程完成为止,对于内存 比较大的实例会造成长时间阻塞,线上环境不建议使用
2. bgsave命令:Redis进程执行fork操作创建子进程,RDB持久化过程由子 进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短
自动触发
略
RDB快照过程中Redis是否会停止对外提供服务
不会,主线程主要是fork一个子线程来进行持久化操作
RDB的优缺点
优点
- 性能最大化,fork子进程来完成写操作,让主进程继续处理命令,保证了redis的高性能
- 重启恢复数据的时候。数据量比较大时候,Redis直接解析RDB二进制文件,生成对应的数据存储在内存中,比AOF的启动效率更高
缺点
- 数据安全性低,因为是间隔一段时间进行持久化,如果在持久化之间发生了故障,会丢失数据,这也就决定了该方式更适合在数据要求不严谨的时候采用
- 系统性能耗费,根据上文提到的Redis执行cow机制时,可以看到大量的分页错误会耗费不少性能在复制上。
AOF
修改内存的操作命令都会记录下来,加入AOF日志记录都是Redis实例创建以来的所有修改性指令序列,所以恢复也就是顺序执行所有执行。
触发RDB的方式
手动触发
bgrewriteaof指令
自动触发
略
AOF优缺点
优点
数据安全,aof持久化配置appendfsync属性,有always,每执行一次命令操作就记录到aof文件一次
缺点
数据集大的时候,比如RDB启动效率低
混合持久化(Redis 4.0版本)
将RDB文件内存和增量的AOF日志文件放在一起,这里的AOF日志不再是全量日志。而是自持久化开始到持久化结束的这段时间的增量日志,通常较小,重启效率因此大幅得到提升。
加载的时候,首先按照RDB格式加载,加载完成后继续按AOF加载剩余的部分。
对比
1. RDB 定期将数据写入文件,体积较小,恢复速度快,但是近期的数据有丢失
2. AOF 记录每秒钟redis日志,体积大,恢复速度较慢,近期的数据基本无丢失
3. 4.0版本开始,就使用两种方式的结合
更多参考
https://juejin.cn/post/6864020770113191943