Redis相关简介_双11活动日,销售手机充值卡的商家对移动、联通、电信的30元、50元、100元的商品推-CSDN博客

本文链接：https://blog.csdn.net/qq_40432598/article/details/128743393

1. Redis 简介

在这个部分，我们将学习以下3个部分的内容，分别是：

◆ Redis 简介（NoSQL概念、Redis概念）

◆ Redis 的下载与安装

◆ Redis 的基本操作

1.1 NoSQL概念

1.1.1 问题现象

在讲解NoSQL的概念之前呢，我们先来看一个现象：

（1）问题现象

每年到了过年期间，大家都会自觉自发的组织一场活动，叫做春运！以前我们买票都是到火车站排队，后来呢有了12306，有了他以后就更方便了，我们可以在网上买票，但是带来的问题，大家也很清楚，春节期间买票进不去，进去了刷不着票。什么原因呢，人太多了！
在这里插入图片描述

除了这种做铁路的，它系统做的不专业以外，还有马爸爸做的淘宝，它面临一样的问题。淘宝也崩，也是用户量太大！作为我们整个电商界的东哥来说，他第一次做图书促销的时候，也遇到了服务器崩掉的这样一个现象，原因同样是因为用户量太大！
在这里插入图片描述

（2）现象特征

再来看这几个现象，有两个非常相似的特征：

第一，用户比较多，海量用户

第二，高并发

这两个现象出现以后，对应的就会造成我们的服务器瘫痪。核心本质是什么呢？其实并不是我们的应用服务器，而是我们的关系型数据库。关系型数据库才是最终的罪魁祸首！

（3）造成原因

什么样的原因导致的整个系统崩掉的呢：

1.性能瓶颈：磁盘IO性能低下

关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。

2.扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群

我们说关系型数据库，它里面表与表之间的关系非常复杂，不知道大家能不能想象一点，就是一张表，通过它的外键关联了七八张表，这七八张表又通过她的外件，每张又关联了四五张表。你想想，查询一下，你要想拿到数据，你就要从A到B、B到C、C到D的一直这么关联下去，最终非常影响查询的效率。同时，你想扩展下，也很难!

（4）解决思路

面对这样的现象，我们要想解决怎么版呢。两方面：

一，降低磁盘IO次数，越低越好。

二，去除数据间关系，越简单越好。

降低磁盘IO次数，越低越好，怎么搞？我不用你磁盘不就行了吗？于是，内存存储的思想就提出来了，我数据不放到你磁盘里边，放内存里，这样是不是效率就高了。

第二，你的数据关系很复杂，那怎么办呢？干脆简单点，我断开你的关系，我不存关系了，我只存数据，这样不就没这事了吗？

把这两个特征一合并一起，就出来了一个新的概念：NoSQL

1.1.2 NoSQL的概念

（1）概念

NoSQL：即 Not-Only SQL（泛指非关系型的数据库），作为关系型数据库的补充。作用：应对基于海量用户和海量数据前提下的数据处理问题。

他说这句话说的非常客气，什么意思呢？就是我们数据存储要用SQL，但是呢可以不仅仅用SQL，还可以用别的东西，那别的东西叫什么呢？于是他定义了一句话叫做NoSQL。这个意思就是说我们存储数据，可以不光使用SQL，我们还可以使用非SQL的这种存储方案，这就是所谓的NoSQL。

（2）特征

可扩容，可伸缩。SQL数据关系过于复杂，你扩容一下难度很高，那我们Nosql 这种的，不存关系，所以它的扩容就简单一些。

大数据量下高性能。包数据非常多的时候，它的性能高，因为你不走磁盘IO，你走的是内存，性能肯定要比磁盘IO的性能快一些。

灵活的数据模型、高可用。他设计了自己的一些数据存储格式，这样能保证效率上来说是比较高的，最后一个高可用，我们等到集群内部分再去它！

（3）常见 Nosql 数据库

目前市面上常见的Nosql产品：Redis、memcache、HBase、MongoDB

（4）应用场景-电商为例

我们以电商为例，来看一看他在这里边起到的作用。

第一类，在电商中我们的基础数据一定要存储起来，比如说商品名称，价格，生产厂商，这些都属于基础数据，这些数据放在MySQL数据库。

第二类，我们商品的附加信息，比如说，你买了一个商品评价了一下，这个评价它不属于商品本身。就像你买一个苹果，“这个苹果很好吃”就是评论，但是你能说很好吃是这个商品的属性嘛？不能这么说，那只是一个人对他的评论而已。这一类数据呢，我们放在另外一个地方，我们放到MongoDB。它也可以用来加快我们的访问，他属于NoSQL的一种。

第三，图片内的信息。注意这种信息相对来说比较固定，他有专用的存储区，我们一般用文件系统来存储。至于是不是分布式，要看你的系统的一个整个瓶颈了？如果说你发现你需要做分布式，那就做，不需要的话，一台主机就搞定了。

第四，搜索关键字。为了加快搜索，我们会用到一些技术，有些人可能了解过，像分ES、Lucene、solr都属于搜索技术。那说的这么热闹，我们的电商解决方案中还没出现我们的redis啊！注意第五类信息。

第五，热点信息。访问频度比较高的信息，这种东西的第二特征就是它具有波段性。换句话说他不是稳定的，它具有一个时效性的。那么这类信息放哪儿了，放到我们的redis这个解决方案中来进行存储。

具体的我们从我们的整个数据存储结构的设计上来看一下。
在这里插入图片描述

我们的基础数据都存MySQL,在它的基础之上，我们把它连在一块儿，同时对外提供服务。向上走，有一些信息加载完以后,要放到我们的MongoDB中。还有一类信息，我们放到我们专用的文件系统中（比如图片），就放到我们的这个搜索专用的，如Lucene、solr及集群里边，或者用ES的这种技术里边。那么剩下来的热点信息，放到我们的redis里面。

1.2 Redis概念

1.2.1 redis概念

概念：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.2 redis的应用场景

（1）为热点数据加速查询（主要场景）。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。
（2）即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等。
（3）时效性信息控制。如验证码控制、投票控制等。
（4）分布式数据共享。如分布式集群架构中的 session 分离
(5) 消息队列.

1.3 Redis 的下载与安装

后期所有资料分4中不同色块显示，详情如下：

在这里插入图片描述

1.3.1 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.4 Redis服务器启动

1.4.1 Redis服务器启动

启动服务器——参数启动

redis-server [--port port]

范例

redis-server --port 6379

启动服务器——配置文件启动

redis-server config_file_name

范例

redis-server redis.conf

1.4.2 Redis客户端启动

启动客户端

redis-cli [-h host] [-p port]

范例

redis-cli –h 61.129.65.248 –p 6384

注意：服务器启动指定端口使用的是–port，客户端启动指定端口使用的是-p。-的数量不同。

1.4.3 Redis基础环境设置约定

创建配置文件存储目录

mkdir conf

创建服务器文件存储目录（包含日志、数据、临时配置文件等）

mkdir data

创建快速访问链接

ln -s redis-5.0.0 redis

Redis基本操作
命令行模式工具使用思考

功能性命令

帮助信息查阅

退出指令

清除屏幕信息

信息读写

设置 key，value 数据

set key value

范例

set name itheima

根据 key 查询对应的 value，如果不存在，返回空（nil）

get key

范例

get name

帮助信息

获取命令帮助文档

help [command]

范例

help set

获取组中所有命令信息名称

help [@group-name]

范例

help @string

1.6.4 退出命令行客户端模式

退出客户端

quit
exit

快捷键

Ctrl+C

数据类型

2.1 数据存储类型介绍

2.1.1 业务数据的特殊性

（1）原始业务功能设计

1 秒杀 他这个里边数据变化速度特别的快，访问量也特别的高，用户大量涌入以后都会针对着一部分数据进行操作，这一类要记住。

2 618活动 对于我们京东的618活动、以及天猫的双11活动，相信大家不用说都知道这些数据一定要进去，因为他们的访问频度实在太高了。

3 排队购票 我们12306的票务信息。这些信息在原始设计的时候，他们就注定了要进redis。

（2）运营平台监控到的突发高频访问数据

此类平台临时监控到的这些数据，比如说现在出来的一个八卦的信息，这个新闻一旦出现以后呢，顺速的被围观了，那么这个时候，这个数据就会变得访量特别高，那么这类信息也要进入进去。

（3）高频、复杂的统计数据

**在线人数:**比如说直播现在很火，直播里边有很多数据，例如在线人数。进一个人出一个人，这个数据就要跳动，那么这个访问速度非常的快，而且访量很高，并且它里边有一个复杂的数据统计，在这里这种信息也要进入到我们的redis中。

**投票排行榜:**投票投票类的信息他的变化速度也比较快，为了追求一个更快的一个即时投票的名次变化，这种数据最好也放到redis中。

2.1.2 Redis 数据类型(5种常用)

基于以上数据特征我们进行分析，最终得出来我们的Redis中要设计5种
数据类型：

string、
hash、
list、
set、
sorted_set/zset（应用性较低）

2.2 string数据类型

在学习第一个数据类型之前，先给大家介绍一下，在随后这部分内容的学习过程中，我们每一种数据类型都分成三块来讲：首先是讲下它的基本操作，接下来讲一些它的扩展操作，最后我们会去做一个小的案例分析。

2.2.1Redis 数据存储格式

在学习string这个数据形式之前，我们先要明白string到底是修饰什么的。我们知道
redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储。

对于这种结构来说，我们用来存储数据一定是一个值前面对应一个名称。我们通过名称来访问后面的值。按照这种形势，我们可以对出来我们的存储格式。前面这一部分我们称为key。后面的一部分称为value，而我们的数据类型，他一定是修饰value的。

在这里插入图片描述

数据类型指的是存储的数据的类型，也就是 value 部分的类型，key 部分永远都是字符串。

2.2.2 string 类型

（1）存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型。

string，他就是存一个字符串儿，注意是value那一部分是一个字符串，它是redis中最基本、最简单的存储数据的格式。

（2）**存储数据的格式：**一个存储空间保存一个数据

每一个空间中只能保存一个字符串信息，这个信息里边如果是存的纯数字，他也能当数字使用，我们来看一下，这是我们的数据的存储空间。

（3）**存储内容：**通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用.

在这里插入图片描述

一个key对一个value，而这个itheima就是我们所说的string类型，当然它也可以是一个纯数字的格式。

2.2.3 string 类型数据的基本操作

（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.3 string 类型数据的扩展操作

2.3.1 string 类型数据的扩展操作

下面我们来看一string的扩展操作，分成两大块：一块是对数字进行操作的，第二块是对我们的key的时间进行操作的。

设置数值数据增加指定范围的值（只针对数字）

incr key k++
127.0.0.1:6379> get k4
"v4v5"
127.0.0.1:6379> set num 1
OK
127.0.0.1:6379> incr num
(integer) 2
127.0.0.1:6379> incr num
(integer) 3
127.0.0.1:6379> incr num
(integer) 4
127.0.0.1:6379> get num
"4"
incrby key increment

incrbyfloat key increment

设置数值数据减少指定范围的值

decr key k--
127.0.0.1:6379> get num
"4"
127.0.0.1:6379> decr num
(integer) 3
127.0.0.1:6379> get num
"3"
decrby key increment

设置数据具有指定的生命周期

setex key seconds value
设置存活时间
127.0.0.1:6379> setex t1 10 tt1
OK
127.0.0.1:6379> get t1
"tt1"
127.0.0.1:6379> get t1
"tt1"
127.0.0.1:6379> get t1
(nil)
127.0.0.1:6379>

psetex key milliseconds value

2.3.2 string 类型数据操作的注意事项

(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主页显示粉丝数与微博数量。

在这里插入图片描述

我们来思考一下：这些信息是不是你进入大V的页面儿以后就要读取这写信息的啊，那这种信息一定要存储到我们的redis中，因为他的访问量太高了！那这种数据应该怎么存呢？我们来一块儿看一下方案！

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.5 hash的基本操作

2.5.1 数据存储的困惑

对象类数据的存储如果具有较频繁的更新需求操作会显得笨重！

在正式学习之前，我们先来看一个关于数据存储的困惑：

在这里插入图片描述

比如说前面我们用以上形式存了数据，如果我们用单条去存的话，它存的条数会很多。但如果我们用json格式，它存一条数据就够了。问题来了，假如说现在粉丝数量发生变化了，你要把整个值都改了。但是用单条存的话就不存在这个问题，你只需要改其中一个就行了。这个时候我们就想，有没有一种新的存储结构，能帮我们解决这个问题呢。

我们一块儿来分析一下：

在这里插入图片描述

如上图所示：单条的话是对应的数据在后面放着。仔细观察：我们看左边是不是长得都一模一样啊，都是对应的表名、ID等的一系列的东西。我们可以将右边红框中的这个区域给他封起来。

那如果要是这样的形式的话，如下图，我们把它一合并，并把右边的东西给他变成这个格式，这不就行了吗？

在这里插入图片描述

这个图其实大家并不陌生，第一，你前面学过一个东西叫hashmap不就这格式吗？第二，redis自身不也是这格式吗？那是什么意思呢？注意，这就是我们要讲的第二种格式，hash。

在这里插入图片描述

在右边对应的值，我们就存具体的值，那左边儿这就是我们的key。问题来了，那中间的这一块叫什么呢？这个东西我们给他起个名儿，叫做field字段。那么右边儿整体这块儿空间我们就称为hash，也就是说hash是存了一个key value的存储空间。

2.5.2 hash 类型

新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息

需要的存储结构：一个存储空间保存多个键值对数据

hash类型：底层使用哈希表结构实现数据存储

在这里插入图片描述

如上图所示，这种结构叫做hash，左边一个key，对右边一个存储空间。这里要明确一点，右边这块儿存储空间叫hash，也就是说hash是指的一个数据类型，他指的不是一个数据，是这里边的一堆数据，那么它底层呢，是用hash表的结构来实现的。

值得注意的是：

如果field数量较少，存储结构优化为类数组结构

如果field数量较多，存储结构使用HashMap结构

2.5.3 hash 类型数据的基本操作

添加/修改数据

hset key field value

127.0.0.1:6379> hset user:123 name itheima
(integer) 1
127.0.0.1:6379> hset user: 123 age 12
(error) ERR wrong number of arguments for HMSET
127.0.0.1:6379> hset user:123 age 12
(integer) 1

获取数据

hget key field
hgetall key

127.0.0.1:6379> hget user:123 name
"itheima"
127.0.0.1:6379> hgetall user:123
1) "name"
2) "itheima"
3) "age"
4) "12"

删除数据

hdel key field1 [field2]

设置field的值，如果该field存在则不做任何操作

hsetnx key field value
127.0.0.1:6379> hdel user:123 age
(integer) 1
127.0.0.1:6379> hgetall user:123
1) "name"
2) "itheima"
127.0.0.1:6379>

添加/修改多个数据

hmset key field1 value1 field2 value2 …
127.0.0.1:6379> hdel user:123 age
(integer) 1
127.0.0.1:6379> hgetall user:123
1) "name"
2) "itheima"
127.0.0.1:6379> hlen user:123
(integer) 1
127.0.0.1:6379> hmset user:123 a a1 b b1 c c1
OK
127.0.0.1:6379> hlen user:123
(integer) 4
127.0.0.1:6379> hgetall user:123
1) "name"
2) "itheima"
3) "a"
4) "a1"
5) "b"
6) "b1"
7) "c"
8) "c1"

获取多个数据

hmget key field1 field2 …

获取哈希表中字段的数量

hlen key

获取哈希表中是否存在指定的字段

hexists key field

2.6 hash的拓展操作

在看完hash的基本操作后，我们再来看他的拓展操作，他的拓展操作相对比较简单：

2.6.1 hash 类型数据扩展操作

获取哈希表中所有的字段名或字段值

hkeys key
hvals key

设置指定字段的数值数据增加指定范围的值

hincrby key field increment
hincrbyfloat key field increment

127.0.0.1:6379> hmset h1 a 123 b 345
OK
127.0.0.1:6379> hincrby h1 a 100
(integer) 223
127.0.0.1:6379> hincrby h1 a -1000
(integer) -777
127.0.0.1:6379> hkeys h1
1) "a"
2) "b"
127.0.0.1:6379> hval h1
(error) ERR unknown command `hval`, with args beginning with: `h1`,
127.0.0.1:6379> hvals h1
1) "-777"
2) "345"
127.0.0.1:6379>

2.6.2 hash类型数据操作的注意事项

(1)hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）。

(2）每个 hash 可以存储 232 - 1 个键值对
hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用。

(3)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基本操作

前面我们存数据的时候呢，单个数据也能存，多个数据也能存，但是这里面有一个问题，我们存多个数据用hash的时候它是没有顺序的。我们平时操作，实际上数据很多情况下都是有顺序的，那有没有一种能够用来存储带有顺序的这种数据模型呢，list就专门来干这事儿。

2.8.1 list 类型

数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分

需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序

list类型：保存多个数据，底层使用双向链表存储结构实现

先来通过一张图，回忆一下顺序表、链表、双向链表。
在这里插入图片描述
list对应的存储结构是什么呢？里边存的这个东西是个列表，他有一个对应的名称。就是key存一个list的这样结构。对应的基本操作，你其实是可以想到的。

来看一下，因为它是双向的，所以他左边右边都能操作，它对应的操作结构两边都能进数据。这就是链表的一个存储结构。往外拿数据的时候怎么拿呢？通常是从一端拿，当然另一端也能拿。如果两端都能拿的话，这就是个双端队列，两边儿都能操作。如果只能从一端进一端出，这个模型咱们前面了解过，叫做栈。

2.8.2 list 类型数据基本操作

最后看一下他的基本操作

添加/修改数据

lpush key value1 [value2] …… 左边放
rpush key value1 [value2] …… 右边放

获取数据

lrange key start stop
lindex key index
llen key

获取并移除数据

lpop key
rpop key
127.0.0.1:6379> lpush list1 zs ls ww zl
(integer) 4
127.0.0.1:6379> lrange list1 0 3
1) "zl"
2) "ww"
3) "ls"
4) "zs"
127.0.0.1:6379> lrange list1 0 -1
1) "zl"
2) "ww"
3) "ls"
4) "zs"
127.0.0.1:6379> lpush list1 hehe
(integer) 5
127.0.0.1:6379> lrange list1 0 -1
1) "hehe"
2) "zl"
3) "ww"
4) "ls"
5) "zs"
127.0.0.1:6379> rpush list1 hehe
(integer) 6
127.0.0.1:6379> lrange list1 0 -1
1) "hehe"
2) "zl"
3) "ww"
4) "ls"
5) "zs"
6) "hehe"
127.0.0.1:6379> lpop list1
"hehe"
127.0.0.1:6379> lrange list1 0 -1
1) "zl"
2) "ww"
3) "ls"
4) "zs"
5) "hehe"
127.0.0.1:6379> llen list1
(integer) 5
127.0.0.1:6379> rpop list1
"hehe"
127.0.0.1:6379> llen list1
(integer) 4

127.0.0.1:6379> lrange list1 0 -1
1) "zl"
2) "ww"
3) "ls"
4) "zs"
127.0.0.1:6379> lindex list1 0
"zl"
127.0.0.1:6379> lindex list1 4
(nil)

2.9 list扩展操作

2.9.1 list 类型数据扩展操作

移除指定数据

lrem key count value

127.0.0.1:6379> lpush list2 a b c d e f g
(integer) 7
127.0.0.1:6379> lrange list2 0 -1
1) "g"
2) "f"
3) "e"
4) "d"
5) "c"
6) "b"
7) "a"
127.0.0.1:6379> lrem list2 1 c
(integer) 1
127.0.0.1:6379> lrange list2 0 -1
1) "g"
2) "f"
3) "e"
4) "d"
5) "b"
6) "a"
127.0.0.1:6379> rpush list2 d e d e d e h e
(integer) 14
127.0.0.1:6379> lrem list2 3 d
(integer) 3
127.0.0.1:6379> rpush list2 d e d e d e h e
(integer) 19
127.0.0.1:6379> lrem list2 3 d
(integer) 3

规定时间内获取并移除数据

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 应用场景

企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

在这里插入图片描述

假如现在你有多台服务器，每一台服务器都会产生它的日志，假设你是一个运维人员，你想看它的操作日志，你怎么看呢？打开A机器的日志看一看，打开B机器的日志再看一看吗？这样的话你会可能会疯掉的！因为左边看的有可能它的时间是11:01，右边11:02，然后再看左边11:03，它们本身是连续的，但是你在看的时候就分成四个文件了，这个时候你看起来就会很麻烦。能不能把他们合并呢？答案是可以的！怎么做呢？建立起redis服务器。当他们需要记日志的时候，记在哪儿,全部发给redis。等到你想看的时候，通过服务器访问redis获取日志。然后得到以后，就会得到一个完整的日志信息。那么这里面就可以获取到完整的日志了，依靠什么来实现呢？就依靠我们的list的模型的顺序来实现。进来一组数据就往里加，谁先进来谁先加进去，它是有一定的顺序的。

2.10.2 解决方案

依赖list的数据具有顺序的特征对信息进行管理

使用队列模型解决多路信息汇总合并的问题

使用栈模型解决最新消息的问题

2.11 set 基本操作

2.11.1 set类型

新的存储需求：存储大量的数据，在查询方面提供更高的效率

需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的

在这里插入图片描述

通过这个名称，大家也基本上能够认识到和我们Java中的set完全一样。我们现在要存储大量的数据，并且要求提高它的查询效率。用list这种链表形式，它的查询效率是不高的，那怎么办呢？这时候我们就想，有没有高效的存储机制。其实前面咱讲Java的时候说过hash表的结构就非常的好，但是这里边我们已经有hash了，他做了这么一个设定，干嘛呢，他把hash的存储空间给改一下，右边你原来存数据改掉,全部存空，那你说数据放哪儿了？放到原来的filed的位置，也就在这里边存真正的值，那么这个模型就是我们的set 模型。

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的。

看一下它的整个结构：
在这里插入图片描述

2.11.2 set类型数据的基本操作

添加数据

sadd key member1 [member2]
127.0.0.1:6379> sadd set1 a
(integer) 1
127.0.0.1:6379> sadd set1 b
(integer) 1
127.0.0.1:6379> sadd set1 v
(integer) 1
127.0.0.1:6379> sadd set1 c
(integer) 1
127.0.0.1:6379> sadd set1 c
(integer) 0
127.0.0.1:6379> sadd set1 a
(integer) 0
127.0.0.1:6379>
不允许重复

获取全部数据

smembers key
127.0.0.1:6379> smembers set1
1) "c"
2) "b"
3) "v"
4) "a"

删除数据

srem key member1 [member2]
127.0.0.1:6379> srem set1 v
(integer) 1
127.0.0.1:6379> srem set1 c
(integer) 1
127.0.0.1:6379> smembers set1
1) "b"
2) "a"
127.0.0.1:6379> srem set1 c
(integer) 0
127.0.0.1:6379>

获取集合数据总量

scard key

127.0.0.1:6379> scard set1
(integer) 2
127.0.0.1:6379>

判断集合中是否包含指定数据

sismember key member

127.0.0.1:6379> sismember set1 c
(integer) 0
127.0.0.1:6379> sismember set1 a
(integer) 1
127.0.0.1:6379>

随机获取集合中指定数量的数据

srandmember key [count]

127.0.0.1:6379> srandmember set1 2
1) "a"
2) "b"
127.0.0.1:6379> srandmember set1
"b"
127.0.0.1:6379> srandmember set1
"a"
127.0.0.1:6379>

随机获取集中的某个数据并将该数据移除集合

spop key [count]

2.12 set 类型数据的扩展操作

2.12.1 set 类型数据的扩展操作

求两个集合的交、并、差集

sinter key1 [key2 …]  
sunion key1 [key2 …]  
sdiff key1 [key2 …]

127.0.0.1:6379> sadd s1 100 666 itheima
(integer) 3
127.0.0.1:6379> sadd s2 100 itheima
(integer) 2
127.0.0.1:6379> sadd s3 666
(integer) 1
127.0.0.1:6379> sadd s4 itcast
(integer) 1
127.0.0.1:6379> sinter s1 s3
1) "666"
127.0.0.1:6379> sinter s1 s2
1) "100"
2) "itheima"
127.0.0.1:6379> sinter s1 s2 s3
(empty list or set)
127.0.0.1:6379>
127.0.0.1:6379> sdiff s1-s2
(empty list or set)
127.0.0.1:6379> sdiff s1 s2
1) "666"
127.0.0.1:6379> sdiff s2 s1
(empty list or set)

求两个集合的交、并、差集并存储到指定集合中

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地址：应用于开放游客访问权限的信息源

黑名单过滤设备信息：应用于限定访问设备的信息源

黑名单过滤用户：应用于基于访问权限的信息源

2.14 实践案例

2.14.1业务场景

使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示。

我们分析一下：

在这里插入图片描述

100这台手机代表你。而200、300、400这三台代表你好友的手机。在这里有一些东西需要交代一下，因为我们每个人的都会对自己的微信中的一些比较重要的人设置会话置顶，将他的那条对话放在最上面。我们假定这个人有两个会话置顶的好友，分别是400和500，而这里边就包含400.

下面呢，我们就来发这个消息，第一个发消息的是300，他发了个消息给100。发完以后，这个东西应该怎么存储呢？在这里面一定要分开，记录置顶的这些人的会话，对应的会话显示顺序和非置顶的一定要分两。

这里面我们创建两个模型，一个是普通的，一个是置顶的，而上面的这个置顶的用户呢，我们用set来存储，因为不重复。而下面这些因为有顺序，很容易想到用list去存储,不然你怎么表达顺序呢？

在这里插入图片描述

那当300发给消息给100以后，这个时候我们先判定你在置顶人群中吗？不在,那好，300的消息对应的顺序就应该放在普通的列表里边。而在这里边，我们把300加进去。第一个数据也就是现在300。

在这里插入图片描述

接下来400，发了个消息。判断一下，他是需要置顶的，所以400将进入list的置顶里边放着。当前还没有特殊的地方。

在这里插入图片描述

再来200发消息了，和刚才的判定方法一样，先看在不在置顶里，不在的话进普通，然后在普通里边把200加入就行了，OK，到这里目前还没有顺序变化。

接下来200又发消息过来，同一个人给你连发了两条，那这个时候200的消息到达以后，先判断是否在置顶范围，不在，接下来他要放在list普通中，这里你要注意一点，因为这里边已经有200，所以进来以后先干一件事儿，把200杀掉，没有200，然后再把200加进来，那你想一下，现在这个位置顺序是什么呢？就是新的都在右边，对不对？

还记得我们说list模型，如果是一个双端队列，它是可以两头进两头出。当然我们双端从一头进一头出，这就是栈模型，现在咱们运用的就是list模型中的栈模型。

在这里插入图片描述