1.Redis简介
1.1NoSQL概念
1.1.1问题现象
第一,用户比较多,海量用户
第二,高并发
这两个现象出现以后,对应的就会造成我们的服务器瘫痪。核心本质是什么呢?其实并不是我们的应用服务器,而是我们的关系型数据库。关系型数据库才是最终的罪魁祸首!
什么样的原因导致的整个系统崩掉的呢:
1.性能瓶颈:磁盘IO性能低下
关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。
2.扩展瓶颈:数据关系复杂,扩展性差,不便于大规模集群
我们说关系型数据库,它里面表与表之间的关系非常复杂,不知道大家能不能想象一点,就是一张表,通过它的外键关联了七八张表,这七八张表又通过她的外件,每张又关联了四五张表。你想想,查询一下,你要想拿到数据,你就要从A到B、B到C、C到D的一直这么关联下去,最终非常影响查询的效率。同时,你想扩展下,也很难!
面对这样的现象,我们要想解决怎么版呢。两方面:
一,降低磁盘IO次数,越低越好。
二,去除数据间关系,越简单越好。
降低磁盘IO次数,越低越好,怎么搞?我不用你磁盘不就行了吗?于是,内存存储的思想就提出来了,我数据不放到你磁盘里边,放内存里,这样是不是效率就高了。
第二,你的数据关系很复杂,那怎么办呢?干脆简单点,我断开你的关系,我不存关系了,我只存数据,这样不就没这事了吗?
把这两个特征一合并一起,就出来了一个新的概念:NoSQL
1.1.2NoSQL概念
(1)概念
NoSQL:即 Not-Only SQL( 泛指非关系型的数据库),作为关系型数据库的补充。 作用:应对基于海量用户和海量数据前提下的数据处理问题。
(2)特征
可扩容,可伸缩。SQL数据关系过于复杂,你扩容一下难度很高,那我们Nosql 这种的,不存关系,所以它的扩容就简单一些。
大数据量下高性能。包数据非常多的时候,它的性能高,因为你不走磁盘IO,你走的是内存,性能肯定要比磁盘IO的性能快一些。
灵活的数据模型、高可用。他设计了自己的一些数据存储格式,这样能保证效率上来说是比较高的,最后一个高可用,我们等到集群内部分再去它!
(3)常见 Nosql 数据库
目前市面上常见的Nosql产品:Redis、memcache、HBase、MongoDB
(4)应用场景-电商为例
我们以电商为例,来看一看他在这里边起到的作用。
第一类,在电商中我们的基础数据一定要存储起来,比如说商品名称,价格,生产厂商,这些都属于基础数据,这些数据放在MySQL数据库。
第二类,我们商品的附加信息,比如说,你买了一个商品评价了一下,这个评价它不属于商品本身。就像你买一个苹果,“这个苹果很好吃”就是评论,但是你能说很好吃是这个商品的属性嘛?不能这么说,那只是一个人对他的评论而已。这一类数据呢,我们放在另外一个地方,我们放到MongoDB。它也可以用来加快我们的访问,他属于NoSQL的一种。
第三,图片内的信息。注意这种信息相对来说比较固定,他有专用的存储区,我们一般用文件系统来存储。至于是不是分布式,要看你的系统的一个整个 瓶颈 了?如果说你发现你需要做分布式,那就做,不需要的话,一台主机就搞定了。
第四,搜索关键字。为了加快搜索,我们会用到一些技术,有些人可能了解过,像分ES、Lucene、solr都属于搜索技术。那说的这么热闹,我们的电商解决方案中还没出现我们的redis啊!注意第五类信息。
第五,热点信息。访问频度比较高的信息,这种东西的第二特征就是它具有波段性。换句话说他不是稳定的,它具有一个时效性的。那么这类信息放哪儿了,放到我们的redis这个解决方案中来进行存储。
1.2Redis概念
1.2.1redis概念
概念:Redis (REmote DIctionary Server) 是用 C 语言开发的一个开源的高性能键值对(key-value)数据库。
特征:
(1)数据间没有必然的关联关系;
(2)内部采用单线程机制进行工作;
(3)高性能。官方提供测试数据,50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
(4)多数据类型支持
字符串类型,string
列表类型,list
散列类型,hash
集合类型,set
有序集合类型,zset/sorted_set
(5)支持持久化,可以进行数据灾难恢复
1.2.2redis的应用场景
(1)为热点数据加速查询(主要场景)。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。
(2)即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息(聊天室、网站)、设备信号等。
(3)时效性信息控制。如验证码控制、投票控制等。
(4)分布式数据共享。如分布式集群架构中的 session 分离
(5)消息队列.
1.3Redis下载和安装
Windows安装:(10条消息) windows下Redis的安装和配置--图文教程_Zepal-CSDN博客_windows下redis安装步骤
基于Center OS7安装Redis。
(1)下载Redis
下载安装包::wget http://download.redis.io/releases/redis-5.0.0.tar.gz
解压安装包: :tar –xvf redis-5.0.0.tar.gz
编译(在解压的目录中执行): make
安装(在解压的目录中执行): make install
(2)安装 Redis
redis-server,服务器启动命令 客户端启动命令
redis-cli,redis核心配置文件
redis.conf,RDB文件检查工具(快照持久化文件)
redis-check-dump,AOF文件修复工具
redis-check-aof
1.4Redis服务器启动
1.4.1Redis服务器启动
启动服务器——参数启动
redis-server [--port port]
范例:redis-server --port 6379
启动服务器——配置文件启动
redis-server config_file_name
范例:redis-server redis.conf
1.4.2Redis客户端启动
启动客户端
redis-cli [-h host] [-p port]
范 例:redis-cli –h 61.129.65.248 –p 6384
注意:服务器启动指定端口使用的是--port,客户端启动指定端口使用的是-p。-的数量不同。
1.4.3Redis基础环境设置约定
创建配置文件存储目录 :mkdir conf
创建服务器文件存储目录(包含日志、数据、临时配置文件等) :mkdir data
创建快速访问链接 :ln -s redis-5.0.0 redis
1.5配置文件启动与常用配置
1.5.1服务器端设定
设置服务器以守护进程的方式运行,开启后服务器控制台中将打印服务器运行信息(同日志内容相同) :daemonize yes|no
绑定主机地址 :bind ip
设置服务器端口 :port port
设置服务器文件保存地址 :dir path
1.5.2客户端配置
服务器允许客户端连接最大数量,默认0,表示无限制。当客户端连接到达上限后,Redis会拒绝新的连接 :maxclients count
客户端闲置等待最大时长,达到最大值后关闭对应连接。如需关闭该功能,设置为 0 :timeout seconds
1.5.3日志配置
设置服务器以指定日志记录级别 :loglevel debug|verbose|notice|warning
日志记录文件名:logfile filename
注意:日志级别开发期设置为verbose即可,生产环境中配置为notice,简化日志输出量,降低写日志IO的频度。
1.6Redis基本操作
1.6.1命令行模式工具使用思考
功能性命令
帮助信息查阅
退出指令
清除屏幕信息
1.6.2信息读写
设置 key,value 数据:set key value
范例:set name itheima
根据 key 查询对应的 value,如果不存在,返回空(nil):get key
范例:get name
1.6.3帮助信息
获取命令帮助文档:help [command]
范例:help set
获取组中所有命令信息名称:help [@group-name]
范例:help @string
1.6.4退出命令行客户端模式
退出客户端:quit | exit
快捷键:Ctrl+C
2.数据类型
2.1数据存储类型的介绍
2.1.1业务数据的特殊性
在讲解数据类型之前,我们得先思考一个问题,数据类型既然是用来描述数据的存储格式的,如果你不知道哪些数据未来会进入到我们来的redis中,那么对应的数据类型的选择,你就会出现问题,我们一块来看一下:
(1)原始业务功能设计
秒杀。他这个里边数据变化速度特别的快,访问量也特别的高,用户大量涌入以后都会针对着一部分数据进行操作,这一类要记住。
618活动。对于我们京东的618活动、以及天猫的双11活动,相信大家不用说都知道这些数据一定要进去,因为他们的访问频度实在太高了。
排队购票。我们12306的票务信息。这些信息在原始设计的时候,他们就注定了要进redis。
(2)运营平台监控到的突发高频访问数据
此类平台临时监控到的这些数据,比如说现在出来的一个八卦的信息,这个新闻一旦出现以后呢,顺速的被围观了,那么这个时候,这个数据就会变得访量特别高,那么这类信息也要进入进去。
(3)高频、复杂的统计数据
在线人数。比如说直播现在很火,直播里边有很多数据,例如在线人数。进一个人出一个人,这个数据就要跳动,那么这个访问速度非常的快,而且访量很高,并且它里边有一个复杂的数据统计,在这里这种信息也要进入到我们的redis中。
投票排行榜。投票投票类的信息他的变化速度也比较快,为了追求一个更快的一个即时投票的名次变化,这种数据最好也放到redis中。
2.1.2Redis数据类型(5种常用)
基于以上数据特征我们进行分析,最终得出来我们的Redis中要设计5种 数据类型:
string、hash、list、set、sorted_set/zset(应用性较低)
2.2String数据类型
2.2.1Redis数据存储格式
在学习string这个数据形式之前,我们先要明白string到底是修饰什么的。我们知道redis 自身是一个 Map,其中所有的数据都是采用 key : value 的形式存储。
对于这种结构来说,我们用来存储数据一定是一个值前面对应一个名称。我们通过名称来访问后面的值。按照这种形势,我们可以对出来我们的存储格式。前面这一部分我们称为key。后面的一部分称为value,而我们的数据类型,他一定是修饰value的。
数据类型指的是存储的数据的类型,也就是 value 部分的类型,key 部分永远都是字符串。
2.2.2String类型
(1)存储的数据:单个数据,最简单的数据存储类型,也是最常用的数据存储类型。
string,他就是存一个字符串儿,注意是value那一部分是一个字符串,它是redis中最基本、最简单的存储数据的格式。
(2)存储数据的格式:一个存储空间保存一个数据
每一个空间中只能保存一个字符串信息,这个信息里边如果是存的纯数字,他也能当数字使用,我们来看一下,这是我们的数据的存储空间。
(3)存储内容:通常使用字符串,如果字符串以整数的形式展示,可以作为数字操作使用.
2.2.3String类型数据的基本操作
(1)基础指令
添加/修改数据添加/修改数据:set key value
获取数据:get key
删除数据:del key
判定性添加数据:setnx key value(如果值为空则添加成功,如果有值则添加失败)
添加/修改多个数据:mset key1 value1 key2 value2 …
获取多个数据:mget key1 key2 …
获取数据字符个数(字符串长度):strlen key
追加信息到原始信息后部(如果原始信息存在就追加,否则新建):append key value
(2)单数据操作与多数据操作的选择之惑
即set 与mset的关系。这对于这两个操作来说,没有什么你应该选哪个,而是他们自己的特征是什么,你要根据这个特征去比对你的业务,看看究竟适用于哪个。
假如说这是我们现在的服务器,他要向redis要数据的话,它会发出一条指令。那么当这条指令发过来的时候,比如说是这个set指令过来,那么它会把这个结果返回给你,这个时候我们要思考这里边一共经过了多长时间。
首先,发送set指令要时间,这是网络的一个时间,接下来redis要去运行这个指令要消耗时间,最终把这个结果返回给你又有一个时间,这个时间又是一个网络的时间,那我们可以理解为:一个指令发送的过程中需要消耗这样的时间.
但是如果说现在不是一条指令了,你要发3个set的话,还要多长时间呢?对应的发送时间要乘3了,因为这是三个单条指令,而运行的操作时间呢,它也要乘3了,但最终返回的也要发3次,所以这边也要乘3。
于是我们可以得到一个结论:单指令发3条它需要的时间,假定他们两个一样,是6个网络时间加3个处理时间,如果我们把它合成一个mset呢,我们想一想。
假如说用多指令发3个指令的话,其实只需要发一次就行了。这样我们可以得到一个结论,多指令发3个指令的话,其实它是两个网络时间加上3个redis的操作时间,为什么这写一个小加号呢,就是因为毕竟发的信息量变大了,所以网络时间有可能会变长。
那么通过这张图,你就可以得到一个结论,我们单指令和多指令他们的差别就在于你发送的次数是多还是少。当你影响的数据比较少的时候,你可以用单指令,也可以用多指令。但是一旦这个量大了,你就要选择多指令了,他的效率会高一些。
2.3String类型数据的扩展操作
2.3.1String类型数据的扩展操作
下面我们来看一string的扩展操作,分成两大块:一块是对数字进行操作的,第二块是对我们的key的时间进行操作的。
设置数值数据增加指定范围的值:
incr key:每次key值加一
incrby key increment:每次key值加increment的大小
incrbyfloat key increment:每次key值加increment浮点数的大小
设置数值数据减少指定范围的值
decr key:
decrby key increment
设置数据具有指定的生命周期
setex key seconds value:设置key值的存活时期seconds(秒)的时间,值为value
psetex key milliseconds value:设置key值的存活时期seconds(毫秒)的时间,值为value
2.3.2String类型数据操作的注意事项
(1)数据操作不成功的反馈与数据正常操作之间的差异
表示运行结果是否成功
(integer) 0 → false 失败
(integer) 1 → true 成功
表示运行结果值
(integer) 3 → 3 3个
(integer) 1 → 1 1个
(2)数据未获取到时,对应的数据为(nil),等同于null
(3)数据最大存储量:512MB
(4)string在redis内部存储默认就是一个字符串,当遇到增减类操作incr,decr时会转成数值型进行计算
(5)按数值进行操作的数据,如果原始数据不能转成数值,或超越了redis 数值上限范围,将报错9223372036854775807(java中Long型数据最大值,Long.MAX_VALUE)
(6)redis所有的操作都是原子性的,采用单线程处理所有业务,命令是一个一个执行的,因此无需考虑并发带来的数据影响.
2.4String应用场景与key命名约定
2.4.1应用场景
它的应用场景在于:主页高频访问信息显示控制,例如新浪微博大V主页显示粉丝数与微博数量。
2.4.2解决方案
(1)在redis中为大V用户设定用户信息,以用户主键和属性值作为key,后台设定定时刷新策略即可。
eg: user:id:3506728370:fans → 12210947
eg: user:id:3506728370:blogs → 6164
eg: user:id:3506728370:focuses → 83
(2)也可以使用json格式保存数据
eg: user:id:3506728370 → {“fans”:12210947,“blogs”:6164,“ focuses ”:83 }
(3) key 的设置约定
数据库中的热点数据key命名惯例
表名 | 主键名 | 主键值 | 字段名 | |
---|---|---|---|---|
eg1: | order | id | 29437595 | name |
eg2: | equip | id | 390472345 | type |
eg3: | news | id | 202004150 | title |
2.5hash的基本操作
2.5.1数据存储的困惑
对象类数据的存储如果具有较频繁的更新需求操作会显得笨重!
左边儿这就是我们的key。问题来了,那中间的这一块叫什么呢?这个东西我们给他起个名儿,叫做field字段。那么右边儿整体这块儿空间我们就称为hash,也就是说hash是存了一个key value的存储空间。
2.5.2 hash类型
新的存储需求:对一系列存储的数据进行编组,方便管理,典型应用存储对象信息
需要的存储结构:一个存储空间保存多个键值对数据
hash类型:底层使用哈希表结构实现数据存储
hash是指的一个数据类型,他指的不是一个数据,是这里边的一堆数据,那么它底层呢,是用hash表的结构来实现的。
值得注意的是:
如果field数量较少,存储结构优化为类数组结构
如果field数量较多,存储结构使用HashMap结构
2.5.3 hash类型数据的基本操作
添加/修改数据:hset key field value
获取数据:
hget key field
hgetall key
删除数据:hdel key field1 [field2]
设置field的值,如果该field存在则不做任何操作:hsetnx key field value
添加/修改多个数据:hmset key field1 value1 field2 value2 …
获取多个数据:hmget key field1 field2 …
获取哈希表中字段的数量:hlen key
获取哈希表中是否存在指定的字段:hexists key field
2.6 hash的扩展操作
2.6.1 hash类型数据扩展操作
获取哈希表中所有的字段名或字段值:
hkeys key
hvals key
设置指定字段的数值数据增加指定范围的值:
hincrby key field increment
hincrbyfloat key field increment
2.6.2 hash类型数据操作的注意事项
(1)hash类型中value只能存储字符串,不允许存储其他数据类型,不存在嵌套现象。如果数据未获取到,对应的值为(nil)。
(2)每个 hash 可以存储 232 - 1 个键值对
(3) hash类型十分贴近对象的数据存储形式,并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计 的,切记不可滥用,更不可以将hash作为对象列表使用。
(4)hgetall 操作可以获取全部属性,如果内部field过多,遍历整体数据效率就很会低,有可能成为数据访问瓶颈。
2.7 hash应用场景
2.7.1应用场景
双11活动日,销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动,每种商品抢购上限1000 张。
最终我们的用户买东西就是在改变这个数量。那你说这个结构应该怎么存呢?对应的商家的ID作为key,然后这些充值卡的ID作为field,最后这些数量作为value。而我们所谓的操作是其实就是increa这个操作,只不过你传负值就行了。
2.7.2 解决方案
以商家id作为key
将参与抢购的商品id作为field
将参与抢购的商品数量作为对应的value
抢购时使用降值的方式控制产品数量
注意:实际业务中还有超卖等实际问题,这里不做讨论
2.8 list基本操作
2.8.1 list类型
数据存储需求:存储多个数据,并对数据进入存储空间的顺序进行区分
需要的存储结构:一个存储空间保存多个数据,且通过数据可以体现进入顺序
list类型:保存多个数据,底层使用双向链表存储结构实现
2.8.2 list类型数据基本操作
左添加数据:lpush key value1 [value2] ……
右添加数据:rpush key value1 [value2] ……
获取数据:
lrange key start stop:获取key中的(lrange key 0 -1:所有元素展示)
lindex key index:查看固定的索引值
llen key:长度
获取并移除数据:
lpop key:获取最后的一个元素
rpop key:取出最后一个元素
2.9List扩展操作
2.9.1list类型数据扩展操作
移除指定数据:lrem key count value(删除key中value的值,并且删除count个)
规定时间内获取并移除数据:
blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout
2.9.2 List类型数据操作注意事项
(1)list中保存的数据都是string类型的,数据总容量是有限的,最多232 - 1 个元素(4294967295)。
(2)list具有索引的概念,但是操作数据时通常以队列的形式进行入队出队操作,或以栈的形式进行入栈出栈操作
(3)获取全部数据操作结束索引设置为-1
(4)list可以对数据进行分页操作,通常第一页的信息来自于list,第2页及更多的信息通过数据库的形式加载
2.10 list应用场景
2.10.1 应用场景
如何保障多台服务器操作日志的统一顺序输出?
建立起redis服务器。当他们需要记日志的时候,记在哪儿,全部发给redis。等到你想看的时候,通过服务器访问redis获取日志。然后得到以后,就会得到一个完整的日志信息。那么这里面就可以获取到完整的日志了,依靠什么来实现呢?就依靠我们的list的模型的顺序来实现。进来一组数据就往里加,谁先进来谁先加进去,它是有一定的顺序的。
2.10.2解决方案
依赖list的数据具有顺序的特征对信息进行管理
使用队列模型解决多路信息汇总合并的问题
使用栈模型解决最新消息的问题
2.11 set基本操作
2.11.1 set类型
新的存储需求:存储大量的数据,在查询方面提供更高的效率
需要的存储结构:能够保存大量的数据,高效的内部存储机制,便于查询
set类型:与hash存储结构完全相同,仅存储键,不存储值(nil),并且值是不允许重复的
2.11.2 set类型数据的基本操作
添加数据:sadd key member1 [member2]
获取全部数据:smembers key
删除数据:srem key member1 [member2]
获取集合数据总量:scard key
判断集合中是否包含指定数据:sismember key member
随机获取集合中指定数量的数据:srandmember key [count]
随机获取集中的某个数据并将该数据移除集合:spop key [count]
2.12 set类型数据的扩展操作
2.12.1 set类型数据的扩展操作
求两个集合的交、并、差集:
sinter key1 [key2 …]
sunion key1 [key2 …]
sdiff key1 [key2 …]
求两个集合的交、并、差集并存储到指定集合中(保存到destination中):
sinterstore destination key1 [key2 …]
sunionstore destination key1 [key2 …]
sdiffstore destination key1 [key2 …]
将指定数据从原始集合中移动到目标集合中
smove source destination member
2.12.2 set类型数据操作的注意事项
set 类型不允许数据重复,如果添加的数据在 set 中已经存在,将只保留一份。
set 虽然与hash的存储结构相同,但是无法启用hash中存储值的空间。
2.13 set应用场景
2.13.1 set应用场景
(1)黑名单
资讯类信息类网站追求高访问量,但是由于其信息的价值,往往容易被不法分子利用,通过爬虫技术, 快速获取信息,个别特种行业网站信息通过爬虫获取分析后,可以转换成商业机密进行出售。例如第三方火 车票、机票、酒店刷票代购软件,电商刷评论、刷好评。
同时爬虫带来的伪流量也会给经营者带来错觉,产生错误的决策,有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后,需要将此类用户进行有效的屏蔽,这就是黑名单的典型应用。
ps:不是说爬虫一定做摧毁性的工作,有些小型网站需要爬虫为其带来一些流量。
(2)白名单
对于安全性更高的应用访问,仅仅靠黑名单是不能解决安全问题的,此时需要设定可访问的用户群体, 依赖白名单做更为苛刻的访问验证。
2.13.2 解决方法
基于经营战略设定问题用户发现、鉴别规则
周期性更新满足规则的用户黑名单,加入set集合
用户行为信息达到后与黑名单进行比对,确认行为去向
黑名单过滤IP地址:应用于开放游客访问权限的信息源
黑名单过滤设备信息:应用于限定访问设备的信息源
黑名单过滤用户:应用于基于访问权限的信息源
3.常用指令
3.1key操作分析
3.1.1key 的相关操作
key是一个字符串,通过key获取redis中保存的数据
对于key自身状态的相关操作,例如:删除,判定存在,获取类型等
对于key有效性控制相关操作,例如:有效期设定,判定是否有效,有效状态的切换等
对于key快速查询操作,例如:按指定策略查询key
3.1.2 key基本操作
删除指定key:del key
获取key是否存在:exists key
获取key的类型:type key
排序:sort key alpha (asc|desc)
改名:
rename key newkey
renamenx key newkey
3.1.3 key扩展操作(时效性控制)
为指定key设置有效期:
expire key seconds:设置秒
pexpire key milliseconds:设置毫秒
expireat key timestamp
pexpireat key milliseconds-timestamp
获取key的有效时间:
ttl key:获取秒
pttl key:获取毫秒
切换key从时效性转换为永久性:persist key
3.1.4 key扩展操作(查询模式)
查询key:keys pattern
查询模式规则:
*匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号
keys * keys 查询所有
it* keys 查询所有以it开头
*heima 查询所有以heima结尾
keys ??heima 查询所有前面两个字符任意,后面以heima结尾 查询所有以
keys user:? user:开头,最后一个字符任意
keys u[st]er:1 查询所有以u开头,以er:1结尾,中间包含一个字母,s或t
3.2数据库指令
3.2.1 key重复问题
一定会,为什么?因为你的key是由程序而定义的。你想写什么写什么,那在使用的过程中大家都在不停的加,早晚有一天他会冲突的。
redis在使用过程中,伴随着操作数据量的增加,会出现大量的数据以及对应的key。
3.2.2 解决方法
redis为每个服务提供有16个数据库,编号从0到15
每个数据库之间的数据相互独立
在对应的数据库中划出一块区域,说他就是几,你就用几那块,同时,其他的这些都可以进行定义,一共是16个,这里边需要注意一点,他们这16个共用redis的内存。没有说谁大谁小,也就是说数字只是代表了一块儿区域,区域具体多大未知。这是数据库的一个分区的一个策略!
3.2.3 数据库的基本操作
切换数据库:select index
其他操作:ping
3.2.4数据库扩展操作
数据移动:move key db
数据总量:dbsize
数据清除:flushdb flushall
4.Jedis简介
用Java来连接redis
4.1Jedis简介
4.1.1 编程语言宇redis
对于我们现在的数据来说,它是在我们的redis中,而最终我们是要做程序。那么程序就要和我们的redis进行连接。干什么事情呢?两件事:程序中有数据的时候,我们要把这些数据全部交给redis管理。同时,redis中的数据还能取出来,回到我们的应用程序中。那在这个过程中,在Java与redis之间打交道的这个东西就叫做Jedis.简单说,Jedis就是提供了Java与redis的连接服务的,里边有各种各样的API接口,你可以去调用它。
除了Jedis外,还有没有其他的这种连接服务呢?其实还有很多,了解一下:
Java语言连接redis服务 Jedis(SpringData、Redis 、 Lettuce)
其它语言:C 、C++ 、C# 、Erlang、Lua 、Objective-C 、Perl 、PHP 、Python 、Ruby 、Scala
4.1.2准备工作
(1)jar包导入
下载地址:https://mvnrepository.com/artifact/redis.clients/jedis
基于maven
(2)客户端连接redis
连接redis
Jedis jedis = new Jedis("localhost", 6379);
操作redis
jedis.set("name", "itheima"); jedis.get("name");
关闭redis连接
jedis.close();
API文档
http://xetorthio.github.io/jedis/
import redis.clients.jedis.Jedis;
import java.util.List;
public class JedisTest {
public static void main(String[] args) {
//1.加载启动(不需要)
//2.获取连接对象
Jedis jedis = new Jedis("172.20.10.3",6379);
jedis.auth("123456");//设置密码
System.out.println("服务正在运行: "+jedis.ping());
//3.执行操作
jedis.set("name","study");
System.out.println(jedis.get("name"));
// jedis.lpush("list1","a","b","c","d","e","f");
// List<String> list1 = jedis.lrange("list1", 0, -1);
// for (String s : list1) {
// System.out.print(s+" ");
// }
// System.out.println("");
jedis.sadd("set1","abc","abc","def");
Long len = jedis.scard("set1");
System.out.println(len);
//4.关闭连接
jedis.close();
}
}
4.2 Jedis建议工具类开发
4.2.1 基于连接池获取链接
JedisPool:Jedis提供的连接池技术
poolConfig:连接池配置对象
host:redis服务地址
port:redis服务端口号
4.2.2封装连接参数
创建jedis的配置文件:jedis.properties
redis.maxTotal=50
redis.maxIdel=10
redis.host=172.20.10.3
redis.port=6379
4.2.3 加载配置信息
创建JedisUtils,使用静态代码块初始化资源
package util;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
import java.util.ResourceBundle;
public class JedisUtils {
private static int maxTotal;
private static int maxIdel;
private static String host;
private static int port;
private static JedisPoolConfig jpc;
private static JedisPool jp;
static {
ResourceBundle bundle = ResourceBundle.getBundle("redis");
maxTotal = Integer.parseInt(bundle.getString("redis.maxTotal"));
maxIdel = Integer.parseInt(bundle.getString("redis.maxIdel"));
host = bundle.getString("redis.host");
port = Integer.parseInt(bundle.getString("redis.port"));
//连接池配置
jpc = new JedisPoolConfig();
jpc.setMaxTotal(maxTotal);
jpc.setMaxIdle(maxIdel);
jp = new JedisPool(jpc,host,port);
}
public static Jedis getJedis(){
Jedis jedis = jp.getResource();
jedis.auth("123456");
return jedis;
}
}
4.3可视化客户端
Redis Desktop Manager
5.持久化
5.1持久化简介
5.1.1 持久化应用场景
假如你现在正在写一个比较重要的文档,如果你要使用的是word,这种办公自动化软件的话,他一旦遇到停电,其实你不用担心,因为它会给你生成一些其他的文件。
自动恢复,其实基于的一个前提就是他提前把你的数据给存起来了。你平常操作的所有信息都是在内存中的,而我们真正的信息是保存在硬盘中的,内存中的信息断电以后就消失了,硬盘中的信息断电以后还可以保留下来!
我们将文件由内存中保存到硬盘中的这个过程,我们叫做数据保存,也就叫做持久化。但是把它保存下来不是你的目的,最终你还要把它再读取出来,它加载到内存中这个过程,我们叫做数据恢复,这就是我们所说的word为什么断电以后还能够给你保留文件,因为它执行了一个自动备份的过程,也就是通过自动的形式,把你的数据存储起来,那么有了这种形式以后,我们的数据就可以由内存到硬盘上实现保存。
5.1.2 什么是持久化
(1)什么是持久化
利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化 。
持久化用于防止数据的意外丢失,确保数据安全性。
(2)持久化过程保存什么?
我们知道一点,计算机中的数据全部都是二进制,如果现在我要你给我保存一组数据的话,你有什么样的方式呢,其实最简单的就是现在长什么样,我就记下来就行了,那么这种是记录纯粹的数据,也叫做快照存储,也就是它保存的是某一时刻的数据状态。
还有一种形式,它不记录你的数据,它记录你所有的操作过程,比如说大家用idea的时候,有没有遇到过写错了ctrl+z撤销,然后ctrl+y还能恢复,这个地方它也是在记录,但是记录的是你所有的操作过程,那我想问一下,操作过程,我都给你留下来了,你说数据还会丢吗?肯定不会丢,因为你所有的操作过程我都保存了。这种保存操作过程的存储,用专业术语来说可以说是日志,这是两种不同的保存数据的形式啊。
总结一下:
第一种:将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据。
第二种:将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程。
5.2 RDB
5.2.1 save指令
手动执行一次保存操作: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
有四个客户端各自要执行一个指令,把这些指令发送到redis服务器后,他们执行有一个先后顺序问题,假定就是按照1234的顺序放过去的话,那会是什么样的?
记得redis是个单线程的工作模式,它会创建一个任务队列,所有的命令都会进到这个队列里边,在这儿排队执行,执行完一个消失一个,当所有的命令都执行完了,OK,结果达到了。
但是如果现在我们执行的时候save指令保存的数据量很大会是什么现象呢?
他会非常耗时,以至于影响到它在执行的时候,后面的指令都要等,所以说这种模式是不友好的,这是save指令对应的一个问题,当cpu执行的时候会阻塞redis服务器,直到他执行完毕,所以说我们不建议大家在线上环境用save指令。
5.2.2bgsave指令
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的过程分成两个过程,第一个是服务端拿到指令直接告诉客户端开始执行了;另外一个过程是一个子进程在完成后台的保存操作,操作完以后回一个消息。
5.2.3 save配置自动执行
设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes
参数
second:监控时间范围
changes:监控key的变化量
其他配置:
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no
5.2.4 RDB三种启动方式对比
方式 | save指令 | bgsave指令 |
---|---|---|
读写 | 同步 | 异步 |
阻塞客户端指令 | 是 | 否 |
额外内存消耗 | 否 | 是 |
启动新进程 | 否 | 是 |
RDB特殊启动形式
服务器运行过程中重启:debug reload
关闭服务器时指定保存数据:shutdown save
RDB优点:
-
RDB是一个紧凑压缩的二进制文件,存储效率较高
-
RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
-
RDB恢复数据的速度要比AOF快很多
-
应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复。
RDB缺点
-
RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
-
bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能
-
Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象
5.3 AOF
为什么要有AOF,这得从RDB的存储的弊端说起:
-
存储数据量较大,效率较低,基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
-
大数据量下的IO性能较低
-
基于fork创建子进程,内存产生额外消耗
-
宕机带来的数据丢失风险
5.3.1 AOF概念
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
5.3.2 AOF执行策略
AOF写数据三种策略(appendfsync)
-
always(每次):每次写入操作均同步到AOF文件中数据零误差,性能较低,不建议使用。
-
everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中,在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高,性能较高,建议使用,也是默认配置
-
no(系统控制):由操作系统控制每次同步到AOF文件的周期,整体过程不可控
5.3.3 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个元素
手动重写: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
5.4 RDB宇AOF区别
5.4.1 RDB宇AOF对比
持久化方式 | RDB | AOF |
---|---|---|
占用存储空间 | 小(数据级:压缩) | 大(指令级:重写) |
存储速度 | 慢 | 快 |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依据策略决定 |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低 | 高 |
5.4.2 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 来恢复数据,降低丢失数据的量
---------------------------------------------------------------------------------------------------------------------------------
内容有部分存在书籍、课堂、网络记录,如有雷同纯属巧合