rdb
RDB
是一种快照存储持久化方式,具体就是将Redis
某一时刻的内存数据保存到硬盘的文件当中,默认保存的文件名为dump.rdb
,而在Redis
服务器启动时,会重新加载dump.rdb
文件的数据到内存当中恢复数据。
1.save命令
save
命令是一个同步操作。当客户端向服务器发送save
命令请求进行持久化时,服务器会阻塞save
命令之后的其他客户端的请求,直到数据同步完成。
2. bgsave
与save
命令不同,bgsave
命令是一个异步操作。
当客户端发服务发出bgsave
命令时,Redis
服务器主进程会forks
一个子进程来数据同步问题,在将数据保存到rdb文件之后,子进程会退出。
所以,与save
命令相比,Redis
服务器在处理bgsave
采用子线程进行IO写入,而主进程仍然可以接收其他请求,但forks
子进程是同步的,所以forks
子进程时,一样不能接收其他请求,这意味着,如果forks一个子进程花费的时间太久(一般是很快的),bgsave命令仍然有阻塞其他客户的请求的情况发生。
3. 服务器配置自动触发
除了通过客户端发送命令外,还有一种方式,就是在Redis
配置文件中的save
指定到达触发RDB持久化的条件,比如【多少秒内至少达到多少写操作】就开启RDB
数据同步。
这种通过服务器配置文件触发RDB的方式,与bgsave命令类似,达到触发条件时,会forks一个子进程进行数据同步,不过最好不要通过这方式来触发RDB持久化,因为设置触发的时间太短,则容易频繁写入rdb文件,影响服务器性能,时间设置太长则会造成数据丢失。
RDB的几个优点
- 与AOF方式相比,通过rdb文件恢复数据比较快。
- rdb文件非常紧凑,适合于数据备份。
- 通过RDB进行数据备,由于使用子进程生成,所以对Redis服务器性能影响较小。
RDB的几个缺点
- 如果服务器宕机的话,采用
RDB
的方式会造成某个时段内数据的丢失,比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次,那么如果还没达到触发条件服务器就死机了,那么这个时间段的数据会丢失。 - 使用save命令会造成服务器阻塞,直接数据同步完成才能接收后续请求。
- 使用bgsave命令在forks子进程时,如果数据量太大,forks的过程也会发生阻塞,另外,forks子进程会耗费内存。
AOF
与RDB
存储某个时刻的快照不同,AOF
持久化方式会记录客户端对服务器的每一次写操作命令,并将这些写操作以Redis
协议追加保存到以后缀为aof
文件末尾,在Redis服务器重启时,会加载并运行aof
文件的命令,以达到恢复数据的目的。
三种写入策略
1. always
客户端的每一个写操作都保存到aof
文件当,这种策略很安全,但是每个写请注都有IO操作,所以也很慢。
2. everysec
appendfsync
的默认写入策略,每秒写入一次aof
文件,因此,最多可能会丢失1s的数据。
3. no
Redis
服务器不负责写入aof
,而是交由操作系统来处理什么时候写入aof
文件。更快,但也是最不安全的选择,不推荐使用。
AOF文件重写 AOF重写方式也是异步操作,即如果要写入aof文件,则Redis主进程会forks一个子进程来处理
AOF将客户端的每一个写操作都追加到aof
文件末尾,比如对一个key多次执行incr命令,这时候,aof
保存每一次命令到aof文件中,aof文件会变得非常大。
incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000
复制代码
aof文件太大,加载aof文件恢复数据时,就会非常慢,为了解决这个问题,Redis支持aof文件重写,通过重写aof,可以生成一个恢复当前数据的最少命令集,比如上面的例子中那么多条命令,可以重写为:
set num 100000
AOF的优点
AOF只是追加日志文件,因此对服务器性能影响较小,速度比RDB要快,消耗的内存较少。
AOF的缺点
-
AOF方式生成的日志文件太大,即使通过AFO重写,文件体积仍然很大。
-
恢复数据的速度比RDB慢。