[转]Redis持久化存储(AOF与RDB两种模式)
Redis中数据存储模式有2种:cache-only,persistence;
- cache-only即只做为“缓存”服务,不持久数据,数据在服务终止后将消失,此模式下也将不存在“数据恢复”的手段,是一种安全性低/效率高/容易扩展的方式;
- persistence即为内存中的数据持久备份到磁盘文件,在服务重启后可以恢复,此模式下数据相对安全。
对于persistence持久化存储,Redis提供了两种持久化方法:
- Redis DataBase(简称RDB)
- Append-only file (简称AOF)
除了这两种方法,Redis在早起的版本还存在虚拟内存的方法,现在已经被废弃。
一、RDB概述
#dbfilename:持久化数据存储在本地的文件
dbfilename dump.rdb
#dir:持久化数据存储在本地的路径,如果是在/redis/redis-3.0.6/src下启动的redis-cli,则数据会存储在当前src目录下
dir ./
##snapshot触发的时机,save <seconds> <changes>
##如下为900秒后,至少有一个变更操作,才会snapshot
##对于此值的设置,需要谨慎,评估系统的变更操作密集程度
##可以通过“save “””来关闭snapshot功能
#save时间,以下分别表示更改了1个key时间隔900s进行持久化存储;更改了10个key300s进行存储;更改10000个key60s进行存储。
save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时,是否阻塞客户端“变更操作”,“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
##是否启用rdb文件压缩,默认为“yes”,压缩往往意味着“额外的cpu消耗”,同时也意味这较小的文件尺寸以及较短的网络传输时间
rdbcompression yes
Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。
./redis-cli -h ip -p port save
./redis-cli -h ip -p port bgsave
除了save m n 以外和手动调用命令外,还有一些其他情况会触发bgsave:
在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点
执行shutdown命令时,自动执行rdb持久化
save m n的实现原理
Redis的save m n,是通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。
serverCron是Redis服务器的周期性操作函数,默认每隔100ms执行一次;该函数对服务器的状态进行维护,其中一项工作就是检查 save m n 配置的条件是否满足,如果满足就执行bgsave。
dirty计数器是Redis服务器维持的一个状态,记录了上一次执行bgsave/save命令后,服务器状态进行了多少次修改(包括增删改);而当save/bgsave执行完成后,会将dirty重新置为0。
例如,如果Redis执行了set mykey helloworld,则dirty值会+1;如果执行了sadd myset v1 v2 v3,则dirty值会+3;注意dirty记录的是服务器进行了多少次修改,而不是客户端执行了多少修改数据的命令。
lastsave时间戳也是Redis服务器维持的一个状态,记录的是上一次成功执行save/bgsave的时间。
save m n的原理如下:每隔100ms,执行serverCron函数;在serverCron函数中,遍历save m n配置的保存条件,只要有一个条件满足,就进行bgsave。对于每一个save m n条件,只有下面两条同时满足时才算满足:
- 当前时间-lastsave > m
- dirty >= n
snapshot执行流程
- Redis父进程首先判断:当前是否在执行save,或bgsave/bgrewriteaof(后面会详细介绍该命令)的子进程,如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。
- 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令
- 父进程fork后,bgsave命令返回”Background saving started”信息并不再阻塞父进程,并可以响应其他命令
- 子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换
- 子进程发送信号给父进程表示完成,父进程更新统计信息
RDB常用配置总结
下面是RDB常用的配置项,以及默认值:
save m n:bgsave自动触发的条件;如果没有save m n配置,相当于自动的RDB持久化关闭,不过此时仍可以通过其他方式触发
stop-writes-on-bgsave-error yes:当bgsave出现错误时,Redis是否停止执行写命令;设置为yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;设置为no,则Redis无视bgsave的错误继续执行写命令,当对Redis服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为no
rdbcompression yes:是否开启RDB文件压缩。Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时,但是可以大大减小RDB文件的体积,因此压缩默认开启;可以通过命令关闭
rdbchecksum yes:是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现
dbfilename dump.rdb:RDB文件名
dir ./:RDB文件和AOF文件所在目录
二、AOF概述
AOF默认关闭,开启方法,修改配置文件reds.conf: appendonly yes
##此选项为aof功能的开关,默认为“no”,可以通过“yes”来开启aof功能
##只有在“yes”下,aof重写/文件同步等特性才会生效
appendonly yes ##指定aof文件名称
appendfilename appendonly.aof ##指定aof操作中文件同步策略,有三个合法值:always everysec no,默认为everysec
appendfsync everysec
##在aof-rewrite期间,appendfsync是否暂缓文件同步,"no"表示“不暂缓”,“yes”表示“暂缓”,默认为“no”
no-appendfsync-on-rewrite no ##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite,默认“64mb”,建议“512mb”
auto-aof-rewrite-min-size 64mb ##相对于“上一次”rewrite,本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后,redis都会记录下此时“新aof”文件的大小(例如A),那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite,每一次aof记录的添加,都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100
- always:每一条aof记录都立即同步到文件,这是最安全的方式,也以为更多的磁盘操作和阻塞延迟,是IO开支较大。
- everysec:每秒同步一次,性能和安全都比较中庸的方式,也是redis推荐的方式。如果遇到物理服务器故障,有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
- no:redis并不直接调用文件同步,而是交给操作系统来处理,操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步;这是一种普通的文件操作方式。性能较好,在物理服务器故障时,数据丢失量会因OS配置有关。
其实,我们可以选择的太少,everysec是最佳的选择。如果你非常在意每个数据都极其可靠,建议你选择一款“关系性数据库”吧。
AOF文件会不断增大,它的大小直接影响“故障恢复”的时间,而且AOF文件中历史操作是可以丢弃的。**AOF rewrite操作就是“压缩”AOF文件的过程,当然redis并没有采用“基于原aof文件”来重写的方式,而是采取了类似snapshot的方式:基于copy-on-write,全量遍历内存中数据,然后逐个序列到aof文件中。因此AOF rewrite能够正确反应当前内存数据的状态,这正是我们所需要的;**rewrite过程中,对于新的变更操作将仍然被写入到原AOF文件中,同时这些新的变更操作也会被redis收集起来(buffer,copy-on-write方式下,最极端的可能是所有的key都在此期间被修改,将会耗费2倍内存),当内存数据被全部写入到新的aof文件之后,收集的新的变更操作也将会一并追加到新的aof文件中,此后将会重命名新的aof文件为appendonly.aof,此后所有的操作都将被写入新的aof文件。如果在rewrite过程中,出现故障,将不会影响原AOF文件的正常工作,只有当rewrite完成之后才会切换文件,因为rewrite过程是比较可靠的。
触发rewrite的时机可以通过配置文件来声明,同时redis中可以通过bgrewriteaof指令人工干预。
redis-cli -h ip -p port bgrewriteaof
因为rewrite操作/aof记录同步/snapshot都消耗磁盘IO,redis采取了“schedule”策略:无论是“人工干预”还是系统触发,snapshot和rewrite需要逐个被执行。
AOF rewrite过程并不阻塞客户端请求。系统会开启一个子进程来完成。
三.总结:
- AOF更加安全,可以将数据更加及时的同步到文件中,但是AOF需要较多的磁盘IO开支,AOF文件尺寸较大,文件内容恢复数度相对较慢。
*2) snapshot,安全性较差,它是“正常时期”数据备份以及master-slave数据同步的最佳手段,文件尺寸较小,恢复数度较快。
可以通过配置文件来指定它们中的一种,或者同时使用它们(不建议同时使用),或者全部禁用,在架构良好的环境中,master通常使用AOF,slave使用snapshot,主要原因是master需要首先确保数据完整性,它作为数据备份的第一选择;slave提供只读服务(目前slave只能提供读取服务),它的主要目的就是快速响应客户端read请求;但是如果你的redis运行在网络稳定性差/物理环境糟糕情况下,建议你master和slave均采取AOF,这个在master和slave角色切换时,可以减少“人工数据备份”/“人工引导数据恢复”的时间成本;如果你的环境一切非常良好,且服务需要接收密集性的write操作,那么建议master采取snapshot,而slave采用AOF。
---------------------
作者:不能说的秘密go
来源:CSDN
原文:https://blog.csdn.net/canot/article/details/52886923
版权声明:本文为作者原创文章,转载请附上博文链接!
内容解析By:CSDN,CNBLOG博客文章一键转载插件
[转]Redis持久化存储(AOF与RDB两种模式)相关推荐
- redis持久化存储AOF与RDB
转载自 https://blog.csdn.net/qq_27384769/article/details/79479048 一.介绍 Redis中数据存储模式有2种:cache-only,persi ...
- redis中存储java对象的两种方式
根据redis的存储原理,Redis的key和value都支持二进制安全的字符串 1.利用序列化和反序列化的方式 存储java对象我们可以通过对象的序列化与反序列化完成存储于取出,这样就可以使用red ...
- Redis详解之-事件订阅和持久化存储方式(RDB和AOF)(二)
转载:https://blog.csdn.net/u010963948/article/details/78881057 对以前的内容进行一下总结和复习. 了解Redis的基本参数配置和使用. 了解事 ...
- Redis windows学习(二)——Redis持久化的AOF模式和RDB模式
AOF和RDB是什么 Redis进行操作时,有两种方式将操作的结果保存下来.一种是将结果以快照的方式保存在二进制文件中(默认叫:dump.rdb* ),这就是RDB模式,另一种是将操作的命令追加到一个 ...
- redis的通用命令 || redis持久化机制:(RDB || AOF)
通用命令 1. keys * : 查询所有的键 2. type key : 获取键对应的value的类型 3. del key:删除指定的key value 持久化 ...
- Redis持久化存储详解(一)
2019独角兽企业重金招聘Python工程师标准>>> 为什么要做持久化存储? 持久化存储是将 Redis 存储在内存中的数据存储在硬盘中,实现数据的永久保存.我们都知道 Redis ...
- 二十二、redis持久化之AOF
AOF(Append Only File) redis是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失.幸好Redis还为我们提供了持久化的机制,分别是RDB( ...
- mysql数据存储方式_数据存储在mysql的两种方式
数据存储在mysql的两种方式 发布时间:2020-05-12 16:16:25 来源:亿速云 阅读:250 作者:三月 下文主要给大家带来数据存储在mysql的两种方式,希望这些内容能够带给大家实际 ...
- Kafuka面试(整合Kafka两种模式区别)
整合Kafka两种模式说明 ★面试题:Receiver & Direct 开发中我们经常会利用SparkStreaming实时地读取kafka中的数据然后进行处理,在spark1.3版本后,k ...
最新文章
- c 清除 html标签,13.4. 去除HTML的标签tag:htmlRemoveTag
- 三人三鬼过河(野人与传教士过河)问题c/c++代码
- arm el2与el3_armv8 memory translation
- ifconfig 命令找不到解决
- flink读写hive-代码方式
- MDOP套装之app-v安装使用及功能说明
- Promise的几个扩展API总结
- 1、Docker部署及基础理论
- 108_Power Pivot购物篮分析分组GENERATE之笛卡尔积、排列、组合
- yii 使用 有赞sdk_有赞 App 动态化配置中心实践
- vue 引入qunee_在vue项目中怎么使用qunee拓扑图插件,怎么正确的使用 graphEditor ?求帮助...
- 根据身份证号判断该人的年龄、性别、出生年月日
- ElasticSearch 高级查询语法
- 坑了程序员的政府项目是什么样的?
- 文件上传漏洞攻击与防御
- 【突变检验合集】含Pettitt突变检验等
- 一种xml解析二次处理的方法(根据剔除规则仅保留部分二级节点)
- 英语论文格式有什么要求?
- Apache OpenNlp的初探
- python特征选择relieff图像特征优选_基于Relief特征选择算法的研究与应用
热门文章
- windows7 + vs2008 + oracle + iis7 客户端配置成功
- TC字符界面-菜单程序【原创】
- ASP.NET Core启动地址配置方法及优先级顺序 | .NET 6 版本
- C# 企业微信消息推送对接,实现天气预报推送
- 如何将自定义的 Delegate 转成 Func 委托?
- 实际体验SpanT 的惊人表现
- C# 9 新特性 —— 增强的 foreach
- 再分享 5 个 vs 调试技巧
- 我们为什么推荐在Json中使用string表示Number属性值
- dotnet core 通过 frp 发布自己的网站