黑马笔记:
RDB:
RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。
快照文件成为RDB文件,默认是保存再当前运行目录。
怎么让Redis执行一下RDB呢?
方式一:save # 由Redis主进程来执行RDB,会阻塞所有命令(不推荐,适用于主动停止Redis进程)
先使用redis-cli连接Redis,再执行save命令,就会执行RDB的备份操作了。但是该执行的操作是由Redis的主进程来完成的,我们知道Redis又是单线程的。一旦主进程来执行RDB,它就不能执行其他操作了,会阻塞所有命令。这时候如果有用户来执行操作,都没法执行。因为主进程在忙着执行RDB的,而RDB操作是需要把数据写到磁盘当中,而磁盘的IO往往是比较慢的。如果你的数据量比较大,这个过程就会耗时比较久。等待执行完成,才会返回一个OK,主进程才能去处理其他的请求。
方式二:bgsave # 开启子进程执行RDB,避免主进程受到影响(适用于在Redis执行的过程中去执行)
在运行这个命令后,会立即返回一个Background saving started(开始后台保存),说明这个保存的命令是在后台异步执行的。
bgsave几乎是0阻塞,为什么是几乎呢?因为把内存中的数据写入RDB的过程确实是异步执行的,但是子进程得来是需要fork主进程的,这个fork的过程是阻塞的,此时的主进程只能干这件事,不能执行用户的请求。(具体细节看黑马Redis98)
Redis停机时会执行一次RDB。
Redis执行save操作,是在主动停机Redis的时候执行,但是如果我们的Redis服务器执行了一个月,没有来得及save,突然宕机了,数据就丢失了。所以,我们希望每隔一段时间,数据就备份一次。
所以在Redis的内部有触发RDB的机制,可以在配置文件中找到:
save 900 1 # 在900s内,如果至少有1个key被修改,则执行bgsave
save 300 10
save 60 1000
RDB的缺点:
RDB执行间隔时间长,两次RDB之间写入数据有丢失的风险。
fork子进程、压缩、写出RDB文件都比较耗时
AOF:
AOF全称为Append Only File(追加文件,因为是不断地记录新的写操作命令,而不是像RDB一样每次都从头开始记录,所以叫追加文件)。Redis处理的每一个写命令都会记录在AOF文件中,可以看作是命令日志文件。
AOF默认是关闭的,需要修改配置文件来开启AOF:
# 是否开启AOF功能,默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF的命令记录的频率也可以通过配置文件来配:
# 表示每执行一次写命令,立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区,然后表示每隔1s将缓冲区数据写到AOF文件,是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
因为AOF记录的是写命令,RDB记录的是数据的值,一个key只能有一个值,但是一个key可以执行多个写的操作。多以AOF文件会币RDB文件大的多。 AOF记录同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在配置中配置:
# AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
总结:
RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用: