Java-JavaWeb—(11)Redis

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:orderid29437595name
eg2:equipid390472345type
eg3:newsid202004150title

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对比

持久化方式RDBAOF
占用存储空间小(数据级:压缩)大(指令级:重写)
存储速度
恢复速度
数据安全性会丢失数据依据策略决定
资源消耗高/重量级低/轻量级
启动优先级

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 来恢复数据,降低丢失数据的量

---------------------------------------------------------------------------------------------------------------------------------

内容有部分存在书籍、课堂、网络记录,如有雷同纯属巧合
 

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

参与评论 您还未登录,请先 登录 后发表或查看评论
©️2022 CSDN 皮肤主题:1024 设计师:我叫白小胖 返回首页

打赏作者

小程来求学

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值