扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章主要讲解了“redis的持久化怎么理解”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“redis的持久化怎么理解”吧!
创新互联专注于禹会企业网站建设,成都响应式网站建设公司,成都商城网站开发。禹会网站建设公司,为禹会等地区提供建站服务。全流程按需求定制设计,专业设计,全程项目跟踪,创新互联专业和态度为您提供的服务
redis的持久化:
概念:将内存中的数据保存到磁盘,在机器宕机或重启时可以保证数据不丢失。
说明:建议RDB和AOF同时开启,若二者同时开启,则redis在启动时优先使用aof文件来恢复数据,若读取aof文件失败,则读取rdb文件来恢复数据。
RDB(Redis DataBase)
概念:
将内存中的数据进行快照并且存储到磁盘上,即在指定目录下生成一个dump.rdb文件。RDB是redis默认的持久化方式。
redis启动后可用通过读取rdb文件,将数据再次载入到内存中,一般情况下1G的rdb文件载入到内存的时间大概为20~30秒。
过程:把所有的数据都写到一个临时文件中,然后用这个临时文件替换掉之前的rdb文件。
触发机制:
手动触发:
save命令:阻塞Redis当前的进程,直到RDB过程完成为止。若实例占用的内存比较大,则会造成redis服务长时间的不可用。(不建议使用)
bgsave命令:redis当前进程执行fork操作创建子进程,RDB持久化过程由子进程负责,父进程继续接收并处理客户端发出的请求。阻塞只发生在fork阶段,一般时间很短。
注意:fork一个进程时,子进程占用的内存空间与父进程相同。
自动触发:
达到配置的条件时,自动触发bgsave命令。
在执行shutdown命令后会自动触发bgsave命令。
配置文件redis.conf:
# 设置触发快照的条件(Will save the DB if both the given number of seconds and the given number of write operations against the DB occurred.)
# 格式:save
save 900 1 # 900秒内,如果有1个以上(包括1个)的key被修改了,则触发快照。
save 300 10 # 300秒内,如果有10个以上(包括10个)的key被修改了,则触发快照。
save 60 10000 # 60秒内,如果有10000个以上(包括10000个)的key被修改了,则触发快照。
# RDB默认会开启,关闭RDB方式的持久化
save ""
# 设置rdb文件的名称
dbfilename dump.rdb
# 设置redis的工作目录,即rdb文件、aof文件所在的目录
# The working directory.
# The DB will be written inside this directory, with the filename specified above using the 'dbfilename' configuration directive.
# The Append Only File will also be created inside this directory.
dir ./
# 设置rdb文件是否进行压缩,默认为yes。注:压缩rdb文件可以减少磁盘空间的占用,但是需要消耗额外的cpu。
rdbcompression yes
优点:适合大规模的数据恢复,且数据加载的速度比较快。
缺点:无法做到数据实时的(秒级)持久化。故数据备份的完整性不高。
AOF(Append Only File)
概念:
将发送到redis服务端的每一条写操作都存储到磁盘上,即在指定目录下生成一个appendonly.aof文件,并且将每次的写操作追加到aof文件的末尾。
redis启动后通过读取aof文件,将aof文件中的写操作依次再执行一遍,以此来达到数据恢复的效果。
过程:命令写入(append)到缓存区、将缓存区的数据同步到aof文件中(sync)、重新aof文件(rewrite)
重写aof文件:
目的:去除数据的中间执行过程,保留最终数据的命令,可大大减小aof文件的大小,从而可以加快数据恢复的速度。
过程:redis当前进程执行fork操作创建子进程(开销等同于bgsave过程),子进程根据命令合并规则将内存中的数据写入到新的AOF文件中,最后用新的aof文件替换掉现有的aof文件。
触发机制:
手动触发:
BGREWRITEAOF
若aof文件格式异常,则需要修复aof文件:redis-check-aof --fix appendonly.aof
自动触发:
达到配置的条件时,自动触发更新aof文件 或 重新aof文件 的操作。
3)配置文件redis.conf:
# AOF和RDB可以同时存在,AOF方式的持久化拥有更好的数据完整性和一致性。
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.
# 开启AOF (AOF默认是关闭的appendonly no)
appendonly yes
# 设置触发更新aof文件的条件
# appendfsync always # 同步持久化,即每次执行写操作后都会去更新aof文件。数据完整性好,但是性能较差。
appendfsync everysec # 每秒同步一次,是AOP默认触发更新日志的条件。
# appendfsync no # 不主动同步,由操作系统来决定什么时候同步(一般为30s),性能最好但是持久化得不到保障,故不推荐使用该配置。
# 设置触发重写aof文件的条件,多个条件是"与"的关系。
# redis在重写aof文件后会将aof文件的大小记录下来(若没有重写过aof文件,则这个大小默认是redis启动时aof文件的大小)
auto-aof-rewrite-percentage 100 # 当前aof文件的大小 超过 上一次重写后记录的大小 的 100%。
auto-aof-rewrite-min-size 64mb # 当前aof文件大于等于64mb。注一般不会设置的这么小,看情况设为ngb比较合理。
# 设置aof文件的名称
# appendfilename appendonly.aof
# 设置redis的工作目录,即rdb文件、aof文件所在的目录
dir ./
优点:可以做到数据实时的(秒级)持久化,故数据备份的完整性很高。
缺点:AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢,故redis在AOF中引入了重写aof文件的机制。
持久化给redis带来的开销:
概念:子进程在重写RDB文件和重写AOF文件时会消耗cpu、内存、硬盘等资源。
cpu:子进程负责把进程内的数据分批写入文件,这个过程属于CPU密集操作,通常子进程对单核CPU利用率接近90%。
内存:父进程fork子进程时,子进程默认占用的内存同父进程一样。我们可以修改Linux内存分配的配置,避免物理内存不足导致fork进程失败。
硬盘:往rdb文件或aof文件中写数据的过程中,磁盘io的压力比较大。
说明:开启AOF的Redis在高流量写入时,如果使用普通机械磁盘,写入吞吐一般在100MB/s左右,这时Redis实例的瓶颈主要在AOF同步硬盘上。
注意:redis实例不应该和其它对cpu、内存、硬盘敏感的服务混部。
感谢各位的阅读,以上就是“redis的持久化怎么理解”的内容了,经过本文的学习后,相信大家对redis的持久化怎么理解这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流