为什么需要持久化
我们都知道redis之所以快,原因之一是因为他操作是在内存之上的。但是我们也知道内存快是快,但是无法保证数据的安全性,一旦发生故障,带来的可能是毁灭性的损失
Redis提供了两种持久化的机制,一种是RDB,另外一种是AOF
RDB持久化机制
RBD持久化机制是基于快照(Snapshot),redis每隔一段时间(用户可以设置)产生一个快照文件(*.dump)进行持久化存储。redis可以通过Save
命令或Bgsave
来触发RDB持久化存储。
Save
在生成快照的期间,会阻塞服务器,在此期间,redis不能进行读写操作
Bgsave
这种方式会通过调用Linux中的fork命令,fork
中实现了COW
(copy on write)读时拷贝,所以bgsave可以概括为 fork cow
区别于sava,他是fork出一个子线程来完成dump文件的生成,并且fork而引起的阻塞相比save方式是非常小的。
Linux中的fork
命令实现了cow
机制,只有当父进程发生写操作,数据发生修改的时候,才会真正分配内存空间,并复制内存数据。
注意:
- 数据是精确到某一时刻的数据,并不是一个时间段
- 复制到内存也中的数据是被修改的数据,并不是全部的内存数据
👍 RBD方式持久化的优点:
- 只有一个dump文件,方便维护,轻量
- 方便数据备份,容灾性好
- 性能最大化,采用fork的方法可以不影响redis服务
- 面对数据集大的时候,比AOF的启动效率高
👎 RBD方式持久化的缺点:
- 安全性比AOF低,因为他是间隔触发的,因此不适合对数据要求特别严苛的场景,比如金融之类的
- fork出的子线程在生成dump的时候也会影响cpu的效率
AOF持久化机制
AOF基于日志的形式进行持久化数据,有点像mysql的binlog。不过binlog存放的是二进制数据,而AOF的日志存放的是一行一行的命令。
流程:
- 所有的写命令都会追加到AOF缓冲中
- AOP缓冲区根据对应的策略向硬盘进行同步操作
- 随着AOF文件越来越大,需要定期对AOF文件进行重写
- 当Redis重启时,可以加载AOF文件进行数据回复
同步策略:
- 每秒同步:异步完成,效率非常高
- 每修改同步:同步完成,每发生一次数据变化都会被立即记录到磁盘中
- 不同步:交给操作系统控制
👍AOF方式持久化的优点:
- 数据安全
- 通过append模式写文件,即使中途宕机也不会破坏已经存在的内容
👎AOF方式持久化的缺点:
- AOF文件比RDB文件大,且回复速度慢
- 数据集打的时候,比RDB启动效率慢
- 运行效率也没有比RDB高
重写机制
随着指令的增加,AOF文件大小也会越来越大。为了压缩文件大小,redis提供了一个文件重写的机制
混合模式
redis4.x开始支持混合模式,开启方式: aof-use-rdb-preamble true
redis在重启时会采用AOF模式,因为RDB数据并不完整;在触发重写机制的时候,会把内存中的数据以RDB的方式写入AOF中,再把AOF缓冲区的数据以AOF写入到文件