Redis持久化
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis持久化,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含7057字,纯文字阅读大概需要11分钟。
内容图文
![Redis持久化](/upload/InfoBanner/zyjiaocheng/868/6fb4229981f4462ab63bf1b556f854fe.jpg)
文章目录
持久化是什么?
(1)什么事持久化?
利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化 。
持久化用于防止数据的意外丢失,确保数据安全性。
(2)持久化过程保存了什么?
计算机中的数据全部都是二进制,如果现在我要你给我保存一组数据的话,你有什么样的方式呢,其实最简单的就是现在长什么样,我就记下来就行了,那么这种是记录纯粹的数据,也叫做快照存储,也就是它保存的是某一时刻的数据状态。
还有一种形式,它不记录你的数据,它记录你所有的操作过程,比如说大家用idea的时候,有没有遇到过写错了ctrl+z撤销,然后ctrl+y还能恢复,这个地方它也是在记录,但是记录的是你所有的操作过程,那我想问一下,操作过程,我都给你留下来了,你说数据还会丢吗?肯定不会丢,因为你所有的操作过程我都保存了。这种保存操作过程的存储,用专业术语来说可以说是日志,这是两种不同的保存数据的形式啊。
总结一下:
第一种:将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据。
第二种:将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程。
正文
1.1save指令
手动执行一次保存操作
save
save指令相关配置
设置本地数据库文件名,默认值为 dump.rdb,通常设置为dump-端口号.rdb
dbfilename filename
设置存储.rdb文件的路径,通常设置成存储空间较大的目录中,目录名称data
dir path
设置存储至本地数据库时是否压缩数据,默认yes,设置为no,节省 CPU 运行时间,但存储文件变大
rdbcompression yes|no
设置读写文件过程是否进行RDB格式校验,默认yes,设置为no,节约读写10%时间消耗,单存在数据损坏的风险
rdbchecksum yes|no
save指令工作原理
需要注意一个问题,来看一下,现在有四个客户端各自要执行一个指令,把这些指令发送到redis服务器后,他们执行有一个先后顺序问题,假定就是按照1234的顺序放过去的话,那会是什么样的?
记得redis是个单线程的工作模式,它会创建一个任务队列,所有的命令都会进到这个队列里边,在这儿排队执行,执行完一个消失一个,当所有的命令都执行完了,OK,结果达到了。
但是如果现在我们执行的时候save指令保存的数据量很大会是什么现象呢?
他会非常耗时,以至于影响到它在执行的时候,后面的指令都要等,所以说这种模式是不友好的,这是save指令对应的一个问题,当cpu执行的时候会阻塞redis服务器,直到他执行完毕,所以说我们不建议大家在线上环境用save指令。
1.2bgsave指令
之前我们讲到了当save指令的数据量过大时,单线程执行方式造成效率过低,那应该如何处理?
此时我们可以使用:bgsave指令,bg其实是background的意思,后台执行的意思
手动启动后台保存操作,但不是立即执行
bgsave
bgsave指令相关配置
后台存储过程中如果出现错误现象,是否停止保存操作,默认yes
stop-writes-on-bgsave-error yes|no
其 他
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
bgsave指令工作原理
当执行bgsave的时候,客户端发出bgsave指令给到redis服务器。注意,这个时候服务器马上回一个结果告诉客户端后台已经开始了,与此同时它会创建一个子进程,使用Linux的fork函数创建一个子进程,让这个子进程去执行save相关的操作,此时我们可以想一下,我们主进程一直在处理指令,而子进程在执行后台的保存,它会不会干扰到主进程的执行吗?
答案是不会,所以说他才是主流方案。子进程开始执行之后,它就会创建啊RDB文件把它存起来,操作完以后他会把这个结果返回,也就是说bgsave的过程分成两个过程,第一个是服务端拿到指令直接告诉客户端开始执行了;另外一个过程是一个子进程在完成后台的保存操作,操作完以后回一个消息。
1.3. save配置自动执行
设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes
参数
second:监控时间范围
changes:监控key的变化量
范例:
save 900 1
save 300 10
save 60 10000
其他相关配置:
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no
save配置工作原理
2.1 AOF概念
为什么要有AOF,这得从RDB的存储的弊端说起:
- 存储数据量较大,效率较低,基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程,内存产生额外消耗
- 宕机带来的数据丢失风险
那解决的思路是什么呢?
- 不写全数据,仅记录部分数据
- 降低区分数据是否改变的难度,改记录数据为记录操作过程
- 对所有操作均进行记录,排除丢失数据的风险
AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式
AOF写数据过程
启动AOF相关配置
开启AOF持久化功能,默认no,即不开启状态
appendonly yes|no
AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof
appendfilename filename
AOF持久化文件保存路径,与RDB持久化文件保持一致即可
dir
AOF写数据策略,默认为everysec
appendfsync always|everysec|no
2.2 AOF执行策略
AOF写数据三种策略(appendfsync)
-
always(每次):每次写入操作均同步到AOF文件中数据零误差,性能较低,不建议使用。
-
everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中,在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高,性能较高,建议使用,也是默认配置
-
no(系统控制):由操作系统控制每次同步到AOF文件的周期,整体过程不可控
2.3 AOF重写
场景:AOF写数据遇到的问题,如果连续执行如下指令该如何处理
什么叫AOF重写?
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。
AOF重写作用
- 降低磁盘占用量,提高磁盘利用率
- 提高持久化效率,降低持久化写时间,提高IO性能
- 降低数据恢复用时,提高数据恢复效率
AOF重写规则
-
进程内具有时效性的数据,并且数据已超时将不再写入文件
-
非写入类的无效指令将被忽略,只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据,但是更改了数据的存储位置,此类命令同样需要记录
-
对同一数据的多条写命令合并为一条命令
如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为:lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
AOF重写方式
- 手动重写
bgrewriteaof
手动重写原理分析:
- 自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent
自动重写触发比对参数( 运行指令info Persistence获取具体信息 )
aof_current_size
aof_base_size
自动重写触发条件公式:
2.4 AOF工作流程及重写流程
RDB与AOF区别
RDB与AOF对比(优缺点)
持久化方式 | RDB | AOF |
---|---|---|
占用存储空间 | 小(数据级:压缩) | 大(指令级:重写) |
存储速度 | 慢 | 快 |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依据策略决定 |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低 | 高 |
RDB与AOF应用场景
RDB与AOF的选择之惑
- 对数据非常敏感,建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出 现问题时,最多丢失0-1秒内的数据。
注意:由于AOF文件存储体积较大,且恢复速度较慢
- 数据呈现阶段有效性,建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段 点数据恢复通常采用RDB方案
注意:利用RDB实现紧凑的数据持久化会使Redis降的很低,慎重总结:
综合比对
- RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
- 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
- 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
- 灾难恢复选用RDB
- 双保险策略,同时开启 RDB和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量
内容总结
以上是互联网集市为您收集整理的Redis持久化全部内容,希望文章能够帮你解决Redis持久化所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。