1、概述
Redis是基于内存的缓存数据库,为了提高性能,所有数据都是存放在内存中的。一旦发生故障,导致Redis服务器宕机,内存中的数据都会丢失。为了在故障发生后能够找回Redis内存中的数据,可以将Redis中内存数据以某种策略持久化到硬盘中,故障恢复时从硬盘中读取数据到内存中,就可以恢复Redis的数据,这就是Redis的持久化。
Redis提供了两种方式的持久化,分别如下:
- RDB(Redis DataBase)
- AOF(Append Of File)
方式 | RDB | AOF |
基本原理 | 将内存中的数据打一个快照,写入到硬盘中。是某一时刻完整的数据。 | 将每一条写命令按顺序写入到缓冲区中(内存),后序根据落盘策略,再将内存缓冲区中的命令追加写入到AOF文件中。 |
工作机制 |
1、手动触发(save命令):会阻塞Redis,内存越大,阻塞时间越长 2、自动触发(bgsave命令):首先fork一个子进程(此阶段会阻塞Redis),之后子进程负责将内存中数据写入到硬盘中。 3、自动触发的时机:可以通过配置文件配置在n秒内执行了n次写操作时自动触发bgsave,也可以关闭自动触发。 4、从节点执行全量复制时,主节点自动触发,并将生成的RDB文件发送给从节点。 5、执行shutdown命令时,如果没有开启AOF,就会自动执行bgsave |
1、通过配置文件appendonly yes设置是否开启AOF,默认不开启 2、所有的写命令首先追加写入到一个内存缓冲区中(目的是提高性能),后序根据落盘策略再将缓冲区中的命令追加写入到AOF文件中 3、随着AOF文件体积的增加,会对AOF文件进行重写,缩小文件体积,节约空间,并加速恢复速度。 4、落盘策略: a)不落盘(未开启AOF) b)定时每隔一段时间落盘 c)写入命令每达到一定数量时落盘 |
优点 |
1、RDB文件体积小,节约空间 2、bgsave后台持久化落盘时阻塞时间短 3、恢复速度快 |
1、故障时丢失数据少 2、持久化时阻塞时间短 |
缺点 | 恢复时丢失的数据量可能较大(最后一次RDB之后的数据都会丢失) |
1、恢复速度慢 2、AOF文件体积大 3、影响Redis写入性能 |
适合场景 | 适合备份、全量复制场景 | 适合做灾难性的误删除紧急恢复 |
注:AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)
2、RDB
2.1、RDB的持久化流程
3、AOF
3.1、AOF持久化流程
(1)客户端的请求写命令会被append追加到AOF缓冲区内;
(2)AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中;
(3)AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
(4)Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的;
3.2、重写(Rewrite)AOF文件
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容重写, 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),redis4.0版本后的重写,是指上就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。
触发机制,何时重写
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。
重写流程
(1)bgrewriteaof触发重写,判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
(2)主进程fork出子进程执行重写操作,保证主进程不会阻塞。
(3)子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
(4)子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
(5)使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。