目录
- 一、Redis持久化介绍
- 二、Redis持久化方式
- 1、RDB持久化
- (1) 介绍
- (2) RDB持久化触发机制
- (3) RDB优点和缺点
- (4) RDB流程
- 2、AOF(append only file)持久化
- (1) 介绍
- (2) AOF优点和缺点
- (3) AOF文件重写
- (4) AOF文件重写流程
- 三、AOF和RDB持久化注意事项
一、Redis持久化介绍
Redis的数据都存放在内存中,如果没有配置持久化,Redis重启后数据就丢失了,于是需要打开Redis的持久化功能,将数据保存到磁盘上,当Redis重启后,可以从磁盘中恢复数据。
二、Redis持久化方式
1、RDB持久化
(1) 介绍
RDB持久化能在指定的时间间隔对你的数据进行快照存储。客户端直接通过命令bgsave或者save来创建一个内存快照。
bgsave
调用fork来创建一个子进程,子进程负责将快照写入磁盘,而父进程则继续处理命令。save
执行过程中,不再响应其它命令。
在redis.conf文件中调整save配置选项,当在规定的时间内,Redis发生了写操作的个数满足条件会触发bgsave命令。
注意:900秒和300秒的意思是Redis每隔900秒、300秒检查写的次数。
(2) RDB持久化触发机制
手动触发:
- 通过
save
命令:会阻塞当前Redis服务器,直到生成完RDB文件,内存比较大的实例会造成长时间的阻塞。 - 通过
bgsave
命令:Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,阻塞只发生在fork阶段。
被动触发:
配置文件中开启save seconds number
配置,自动触发bgsave。从节点执行全量复制,主节点自动执行bgsave生成rdb文件。
备注:默认情况下客户端执行shutdown命令,如果没有开启aof持久化则自动执行bgsave。
(3) RDB优点和缺点
(4) RDB流程
- Redis Fork一个子进程,此时有父、子两个进程。
- 子进程开始写入数据集到临时的RDB文件中。
- 子进程完成写入新的RDB文件后,替换掉旧的。
备注:这种方式利用了写时复制。
2、AOF(append only file)持久化
(1) 介绍
AOF持久化记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复复原始的数据。
注意:建议使用默认的策略每秒同步,这种策略相对快且安全。
(2) AOF优点和缺点
补充:
- 相同数据集AOF文件通常比RDB大。
- AOF持久化更慢,取决与具体的
fsync
策略。 - 如果重写过程中有写的请求,AOF可能需要更多的内存。
- 重写过程中,所有写的命令会刷到磁盘两次。
(3) AOF文件重写
不断的写入操作会导致AOF文件越来越大,例如:如果使用incr
命令对某个key累加100次,最后的值为100,但AOF文件中会有100条记录,前面99条实际上是无用的。
因此Redis支持一个特性:后台重建AOF,而不影响对外服务,通过发起BGREWRITEAOF命令可以实现AOF文件重写。
在Redis2.2版本中使用AOF每次都需要运行BGREWRITEAOF
命令,Redis2.4版本通过配置可以触发自动重写,自动重写默认配置项如下:
auto-aof-rewrite-percentage 100
:如果当前aof文件大小与上次重写后AOF文件大小的增长百分比为100%,则进行触发BGREWRITEAOF进行自动重写,例如:上次重写后AOF文件大小为5m,当前AOF文件大小为10m,增长百分比为(10-5)/5=100%。auto-aof-rewrite-min-size 64mb
:为了避免符合增长百分比触发AOF重写,但AOF文件仍然很小的情况,可以指定重写时的最小文件大小,只有两项条件都满足才触发AOF重写。
(4) AOF文件重写流程
AOF文件重写和RDB也是同样的套路,也是copy-on-write
,具体流程如下:
- Redis fork一个子进程,此时有父、子两个进程。
- 子进程开始在临时文件写入新的AOF内容。
- 父进程把所有新的数据变化命令累积到内存缓冲中(同时把新的数据变化命令写到旧的AOF文件),如果重写失败,数据不会丢失。
- 子进程完成AOF文件重写后通知父进程,父进程收到信号后,把内存缓冲中的命令追加到子进程生成的新AOF文件末尾。
- Redis自动对新文件重命名为旧文件的AOF文件名,新的数据变化命令追加到新的AOF文件中。
三、AOF和RDB持久化注意事项
Redis2.4以上版本要避免RDB持久化时触发AOF重写,或者AOF重写时进行BGSAVE
操作,不然两者同时进行磁盘I/O负载很大。
当RDB在进行中时,此时用户请求AOF文件重写,服务器会响应状态码OK,以告知用户操作正在计划中,一旦内存快照生成,AOF文件重新就会开始。
如果AOF和RDB都启用,那么Redis重启时会优先使用AOF文件进行数据集重建,因为AOF能确保数据是最完整的。