【愚公系列】2023年03月 Java教学课程 123-Redis的概念与基本使用

文章目录

• 一、Redis基础
• • 1. Redis 简介
  • • 1.1 NoSQL概念
    • • 1.1.1 问题现象
      • 1.1.2 NoSQL的概念
    • 1.2 Redis概念
    • • 1.2.1 redis概念
      • 1.2.2 redis的应用场景
    • 1.3 Redis 的下载与安装
    • • 1.3.1 Redis 的下载与安装
    • 1.4 Redis服务器启动
    • • 1.4.1 Redis服务器启动
      • 1.4.2 Redis客户端启动
      • 1.4.3 Redis基础环境设置约定
    • 1.5 配置文件启动与常用配置
    • • 1.5.1 服务器端设定
      • 1.5.2 客户端配置
      • 1.5.3 日志配置
    • 1.6 Redis基本操作
    • • 1.6.1 命令行模式工具使用思考
      • 1.6.2 信息读写
      • 1.6.3 帮助信息
  • 2. 数据类型
  • • 2.1 数据存储类型介绍
    • • 2.1.1 业务数据的特殊性
      • 2.1.2 Redis 数据类型(5种常用)
    • 2.2 string数据类型
    • • 2.2.1Redis 数据存储格式
      • 2.2.2 string 类型
      • 2.2.3 string 类型数据的基本操作
    • 2.3 string 类型数据的扩展操作
    • • 2.3.1 string 类型数据的扩展操作
      • 2.3.2 string 类型数据操作的注意事项
    • 2.4string应用场景与key命名约定
    • • 2.4.1 应用场景
      • 2.4.2 解决方案
    • 2.5 hash的基本操作
    • • 2.5.1 数据存储的困惑
      • 2.5.2 hash 类型
      • 2.5.3 hash 类型数据的基本操作
    • 2.6 hash的拓展操作
    • • 2.6.1 hash 类型数据扩展操作
      • 2.6.2 hash类型数据操作的注意事项
    • 2.7 hash应用场景
    • • 2.7.1 应用场景
      • 2.7.2 解决方案
    • 2.8 list基本操作
    • • 2.8.1 list 类型
      • 2.8.2 list 类型数据基本操作
    • 2.9 list扩展操作
    • • 2.9.1 list 类型数据扩展操作
      • 2.9.2 list 类型数据操作注意事项
    • 2.10 list 应用场景
    • • 2.10.1 应用场景
      • 2.10.2 解决方案
    • 2.11 set 基本操作
    • • 2.11.1 set类型
      • 2.11.2 set类型数据的基本操作
    • 2.12 set 类型数据的扩展操作
    • • 2.12.1 set 类型数据的扩展操作
      • 2.12.2 set 类型数据操作的注意事项
    • 2.13 set应用场景
    • • 2.13.1 set应用场景
      • 2.13.2 解决方案
    • 2.14 实践案例
    • • 2.14.1业务场景
      • 2.14.2 解决方案
      • 2.14.3 数据类型总结
  • 3. 常用指令
  • • 3.1 key 操作分析
    • • 3.1.1 key应该设计哪些操作？
      • 3.1.2 key 基本操作
      • 3.1.3 key 扩展操作（时效性控制）
      • 3.1.4 key 扩展操作（查询模式）
    • 3.2 数据库指令
    • • 3.2.1 key 的重复问题
      • 3.2.2 解决方案
      • 3.2.3 数据库的基本操作
      • 3.2.4 数据库扩展操作

一、Redis基础

1. Redis 简介

1.1 NoSQL概念

1.1.1 问题现象

NoSQL诞生的业务现象是由于传统的关系型数据库在处理大规模数据时存在性能瓶颈和扩展性不足的问题，而NoSQL数据库则能够更好地应对这些挑战，因此在大数据、互联网、移动应用等领域得到了广泛应用。NoSQL数据库具有高可扩展性、高性能、灵活的数据模型等特点，能够满足不同业务场景的需求。因此，许多企业和组织都开始采用NoSQL数据库来支持其业务应用。

NoSQL的优势主要包括以下几个方面：

• 大规模数据处理：Web 2.0时代的网站、社交媒体、移动应用等业务产生了海量的数据，传统的关系型数据库无法满足大规模数据处理的需求。
• 高并发访问：Web 2.0时代的业务需要支持大量用户同时访问，传统的关系型数据库在高并发访问时性能下降明显。
• 非结构化数据：Web 2.0时代的业务数据种类繁多，不仅包括结构化数据，还包括文本、图像、音频、视频等非结构化数据，传统的关系型数据库无法有效地处理非结构化数据。
• 高可扩展性：Web 2.0时代的业务需要支持高可扩展性，能够随着业务的发展不断扩展，传统的关系型数据库在可扩展性方面存在较大的限制。

1.1.2 NoSQL的概念

1、概念

NoSQL是指非关系型数据库，其设计目的在于解决关系型数据库在处理大量分散数据时遇到的问题。NoSQL数据库不使用SQL作为查询语言，以键值对、文档型、列型、图型等方式存储数据。NoSQL数据库具有高可扩展性、高性能、灵活性强等特点，适合处理海量数据和高并发访问。NoSQL数据库适用于Web应用、大数据、云计算等领域。

2、特征

• 非关系型：NoSQL数据库不是基于关系模型的，而是基于其他数据模型，如键值对、文档、图形等。
• 分布式：NoSQL数据库通常是分布式的，可以横向扩展，支持分布式存储和处理大规模数据。
• 高可用性：NoSQL数据库通常具有高可用性，采用多副本机制，可以在节点故障时自动进行故障转移。
• 无固定模式：NoSQL数据库通常不需要预先定义数据模式，可以自由地添加、修改和删除数据。
• 高性能：NoSQL数据库通常采用内存计算和异步写入等技术，能够实现高速读写操作。
• 灵活性：NoSQL数据库通常支持多种查询方式，包括关系查询、全文搜索、地理空间查询等。
• 大数据支持：NoSQL数据库通常支持海量数据的存储和处理，能够快速处理大规模数据集。

3、常见 Nosql 数据库

目前市面上常见的NoSQL数据库包括MongoDB、Cassandra、Redis、HBase、Couchbase等。每种数据库都有其特点和适用场景，需要根据具体业务需求进行选择。

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 分离消息队列.

1.3 Redis 的下载与安装

1.3.1 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

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.6 Redis基本操作

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.2 Redis 数据类型(5种常用)

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

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

2.2 string数据类型

2.2.1Redis 数据存储格式

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的关系。这对于这两个操作来说，没有什么你应该选哪个，而是他们自己的特征是什么，你要根据这个特征去比对你的业务，看看究竟适用于哪个。

在这里插入图片描述

单指令发3条它需要的时间，假定他们两个一样，是6个网络时间加3个处理时间，如果我们把它合成一个mset呢，我们想一想。

多指令发3个指令的话，其实它是两个网络时间加上3个redis的操作时间，为什么这写一个小加号呢，就是因为毕竟发的信息量变大了，所以网络时间有可能会变长。

单指令和多指令他们的差别就在于你发送的次数是多还是少。当你影响的数据比较少的时候，你可以用单指令，也可以用多指令。但是一旦这个量大了，你就要选择多指令了，他的效率会高一些。

2.3 string 类型数据的扩展操作

2.3.1 string 类型数据的扩展操作

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

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

incr key
incrby key increment
incrbyfloat key increment

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

decr key
decrby key increment

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

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

在这里插入图片描述

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命名惯例

2.5 hash的基本操作

2.5.1 数据存储的困惑

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

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

在这里插入图片描述

比如说前面我们用以上形式存了数据，如果我们用单条去存的话，它存的条数会很多。但如果我们用json格式，它存一条数据就够了。问题来了，假如说现在粉丝数量发生变化了，你要把整个值都改了。但是用单条存的话就不存在这个问题，你只需要改其中一个就行了。这个时候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

获取数据

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的拓展操作

在看完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 个键值对 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

2.9 list扩展操作

2.9.1 list 类型数据扩展操作

移除指定数据

lrem key count value

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

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），并且值是不允许重复的

在这里插入图片描述

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 …]

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

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模型中的栈模型。

在这里插入图片描述

现在300发消息，先判定他在不在，不在，用普通的队列，接下来按照刚才的操作，不管你里边原来有没有300，我先把300杀掉，没了，200自然就填到300的位置了，他现在是list里面唯一一个，然后让300进来，注意是从右侧进来的，那么现在300就是最新的。

在这里插入图片描述

那么到这里呢，我们让100来读取消息。你觉得这个消息顺序应该是什么样的？首先置顶的400有一个，他跑在最上面，然后list普通如果出来的话，300是最新的消息，而200在他后面的。用这种形式，我们就可以做出来他的消息顺序来。

2.14.2 解决方案

看一下最终的解决方案：

依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用

置顶与普通会话分别创建独立的list分别管理

当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）

多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id

推送消息时先推送置顶会话list，再推送普通会话list，推送完成的list清除所有数据 消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

2.14.3 数据类型总结

总结一下，在整个数据类型的部分，我们主要介绍了哪些内容：

首先我们了解了一下数据类型，接下来针对着我们要学习的数据类型，进行逐一讲解了string、hash、list、set等，最后通过一个案例总结了一下前面的数据类型的使用场景。

3. 常用指令

在这部分中呢，我们家学习两个知识，第一个是key的常用指令，第二个是数据库的常用指令。和前面我们学数据类型做一下区分，前面你学的那些指令呢，都是针对某一个数据类型操作的，现在学的都是对所有的操作的，来看一下，我们在学习Key的操作的时候，我们先想一下的操作我们应该学哪些东西:

3.1 key 操作分析

3.1.1 key应该设计哪些操作？

key是一个字符串，通过key获取redis中保存的数据

对于key自身状态的相关操作，例如：删除，判定存在，获取类型等

对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

对于key快速查询操作，例如：按指定策略查询key

3.1.2 key 基本操作

删除指定key

del key

获取key是否存在

exists key

获取key的类型

type key

3.1.3 拓展操作

排序

sort

改名

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 的重复问题

在这个地方我们来讲一下数据库的常用指令，在讲这个东西之前，我们先思考一个问题：

假如说你们十个人同时操作redis，会不会出现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