关系型数据库的问题
1.性能瓶颈:磁盘IO性能低下
关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。
2.扩展瓶颈:数据关系复杂,扩展性差,不便于大规模集群
我们说关系型数据库,它里面表与表之间的关系非常复杂,不知道大家能不能想象一点,就是一张表,通过它的外键关联了七八张表,这七八张表又通过她的外件,每张又关联了四五张表。你想想,查询一下,你要想拿到数据,你就要从A到B、B到C、C到D的一直这么关联下去,最终非常影响查询的效率。同时,你想扩展下,也很难!
解决思路
面对这样的现象,我们要想解决怎么版呢。两方面:
一,降低磁盘IO次数,越低越好。
二,去除数据间关系,越简单越好。
降低磁盘IO次数,越低越好,怎么搞?我不用你磁盘不就行了吗?于是,内存存储的思想就提出来了,我数据不放到你磁盘里边,放内存里,这样是不是效率就高了。
第二,你的数据关系很复杂,那怎么办呢?干脆简单点,我断开你的关系,我不存关系了,我只存数据,这样不就没这事了吗?
把这两个特征一合并一起,就出来了一个新的概念:NoSQL
NoSQL的概念
(1)概念
NoSQL:即 Not-Only SQL(不仅仅是SQL 泛指非关系型的数据库),作为关系型数据库的补充。 作用:应对基于海量用户和海量数据前提下的数据处理问题。
(2)特征
1可扩容,可伸缩。SQL数据关系过于复杂,你扩容一下难度很高,那我们Nosql 这种的,不存关系,所以它的扩容就简单一些。
2大数据量下高性能。包数据非常多的时候,它的性能高,因为你不走磁盘IO,你走的是内存,性能肯定要比磁盘IO的性能快一些。
3灵活的数据模型、高可用。他设计了自己的一些数据存储格式,这样能保证效率上来说是比较高的,最后一个高可用,我们等到集群内部分再去它!
(3)应用场景(热点信息)
我们以电商为例,来看一看他在这里边起到的作用。
第一类,在电商中我们的基础数据一定要存储起来,比如说商品名称,价格,生产厂商,这些都属于基础数据,这些数据放在MySQL数据库。
第二类,我们商品的附加信息,比如说,你买了一个商品评价了一下,这个评价它不属于商品本身。就像你买一个苹果,“这个苹果很好吃”就是评论,但是你能说很好吃是这个商品的属性嘛?不能这么说,那只是一个人对他的评论而已。这一类数据呢,我们放在另外一个地方,我们放到MongoDB。它也可以用来加快我们的访问,他属于NoSQL的一种。
第三,图片内的信息。注意这种信息相对来说比较固定,他有专用的存储区,我们一般用文件系统来存储。至于是不是分布式,要看你的系统的一个整个 瓶颈 了?如果说你发现你需要做分布式,那就做,不需要的话,一台主机就搞定了。
第四,搜索关键字。为了加快搜索,我们会用到一些技术,有些人可能了解过,像分ES、Lucene、solr都属于搜索技术。那说的这么热闹,我们的电商解决方案中还没出现我们的redis啊!注意第五类信息。
第五,热点信息。访问频度比较高的信息,这种东西的第二特征就是它具有波段性。换句话说他不是稳定的,它具有一个时效性的。那么这类信息放哪儿了,放到我们的redis这个解决方案中来进行存储。
Redis特征:
(1)数据间没有必然的关联关系;
(2)内部采用单线程机制进行工作;
(3)高性能。官方提供测试数据,50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
(4)多数据类型支持
String ,List ,Hash,Set,Zset(用的比较少)
(5)支持持久化,可以进行数据灾难恢复
redis的应用场景
(1)为热点数据加速查询(主要场景)。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。
(2)即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息(聊天室、网站)、设备信号等。
(3)时效性信息控制。如验证码控制、投票控制等。
(4)分布式数据共享。如分布式集群架构中的 session 分离 消息队列.
五种数据类型
数据类型指的是存储的数据的类型,也就是 value 部分的类型,key 部分永远都是字符串。
持久化
两种持久化方式
1.我们知道一点,计算机中的数据全部都是二进制,如果现在我要你给我保存一组数据的话,你有什么样的方式呢,其实最简单的就是现在长什么样,我就记下来就行了,那么这种是记录纯粹的数据,也叫做快照存储,也就是它保存的是某一时刻的数据状态。
2.还有一种形式,它记录你所有的操作过程,比如说大家用idea的时候,有没有遇到过写错了ctrl+z撤销,然后ctrl+y还能恢复,这个地方它是在记录你所有的操作过程,操作过程,都给你留下来了,数据肯定不会丢。这种保存操作过程的存储,用专业术语来说可以说是日志。
总结一下:
第一种:将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据。
第二种:将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程。
RDB
1.save指令
手动执行一次保存操作
save指令相关配置
设置本地数据库文件名,默认值为 dump.rdb,通常设置为dump-端口号.rdb
dbfilename filename
由于Redis单线程,当cpu执行的时候会阻塞redis服务器,直到他执行完毕,所以说我们不建议大家用save指令。
2. bgsave指令
之前我们讲到了当save指令的数据量过大时,单线程执行方式造成效率过低,那应该如何处理?
此时我们可以使用:bgsave指令,bg其实是background的意思,后台执行的意思
手动启动后台保存操作,但不是立即执行
当执行bgsave的时候,客户端发出bgsave指令给到redis服务器。注意,这个时候服务器马上回一个结果告诉客户端后台已经开始了,与此同时它会创建一个子进程,使用Linux的fork函数创建一个子进程,让这个子进程去执行save相关的操作。
他才是主流方案。子进程开始执行之后,它就会创建啊RDB文件把它存起来,操作完以后他会把这个结果返回,也就是说bgsave的过程分成两个过程,第一个是服务端拿到指令直接告诉客户端开始执行了;另外一个过程是一个子进程在完成后台的保存操作,操作完以后回一个消息。
3 save配置自动执行
设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化(使用bgsave)
save second changes
参数: second(监控时间范围), changes(监控key的变化量)
范例:
save 900 1
save 300 10
save 60 10000
RDB特殊启动形式
服务器运行过程中重启
debug reload
关闭服务器时指定保存数据
shutdown save
全量复制(在主从复制中详细讲解)
RDB优点:
-
RDB是一个紧凑压缩的二进制文件,存储效率较高
-
RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
-
RDB恢复数据的速度要比AOF快很多
-
应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复。
RDB缺点:
-
两个时间点之间,具有较大的可能性丢失数据
-
数据量较大时,效率低下
-
bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能
-
Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象
AOF
因为RDB有许多缺点,所以又有了AOF
AOF概念
AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式
启动AOF相关配置
开启AOF持久化功能,默认no,即不开启状态
appendonly yes
AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof
appendfilename filename
AOF持久化文件保存路径,与RDB持久化文件保持一致即可
AOF写数据策略,默认为everysec(每秒)
appendfsync always|everysec|no
AOF重写
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。
AOF重写作用
-
降低磁盘占用量,提高磁盘利用率
-
提高持久化效率,降低持久化写时间,提高IO性能
-
降低数据恢复用时,提高数据恢复效率
AOF重写规则
-
进程内具有时效性的数据,并且数据已超时将不再写入文件
-
非写入类的无效指令将被忽略,只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据,但是更改了数据的存储位置,此类命令同样需要记录
-
对同一数据的多条写命令合并为一条命令
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
AOF重写方式
-
手动重写
bgrewriteaof
-
自动重写
auto-aof-rewrite-min-size size (内存大小)
auto-aof-rewrite-percentage percentage (内存百分比)
RDB与AOF区别
RDB与AOF对比(优缺点)
持久化方式 | RDB | AOF |
---|---|---|
占用存储空间 | 小(数据级:压缩) | 大(指令级:重写) |
存储速度 | 慢(每次存所以) | 快(每次存部分) |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依据策略决定 |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低 | 高 |
5.4.2 RDB与AOF应用场景
RDB与AOF的选择之惑
-
对数据非常敏感,建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出 现问题时,最多丢失0-1秒内的数据。
注意:由于AOF文件存储体积较大,且恢复速度较慢
-
数据呈现阶段有效性,建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段 点数据恢复通常采用RDB方案
灾难恢复选用RDB
注意:利用RDB实现紧凑的数据持久化会使Redis降的很低,慎重总结:
-
同时开启 RDB和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量