Redis 数据操作
数据存储类型介绍
业务数据类型的选择
在讲解数据类型之前，我们得先思考一个问题，数据类型既然是用来描述数据的存储格式的，如果不知道哪些数据未来会进入到 redis 中，那么对应的数据类型的选择就会出现问题。以下为常见的 Redis 数据存储场景：
-
原始业务功能设计-
秒杀。他这个里边数据变化速度特别的快，访问量也特别的高，用户大量涌入以后都会针对着一部分数据进行操作。
-
电商大促活动。对于我们京东的 618 活动、以及天猫的双 11 活动，其访问频度实在太高了。
-
排队购票。我们 12306 的票务信息在原始设计的时候，就注定了要进 redis。
-
-
运营平台监控到的
突发高频访问数据
- 此类平台临时监控到的这些数据，比如突发一个八卦信息，迅速被围观了，那么这时这个数据就会变得访量特别高，那么这类信息也要进入进去。
高频、复杂的统计数据
-
在线人数。比如说直播现在很火，直播里边有很多数据，例如在线人数。进一个人出一个人，这个数据就要跳动，那么这个访问速度非常地快，而且访量很高，并且它里边有一个复杂的数据统计，在这里这种信息也要进入到我们的 redis 中。
-
投票排行榜。投票投票类的信息他的变化速度也比较快，为了追求一个更快的一个即时投票的名次变化，这种数据最好也放到 redis 中。
基于以上数据特征我们进行分析，最终得出来我们的 Redis 中要设计 5 种数据类型：
- string
- hash
- list
- set
- sorted_set/zset（应用性较低）
关于数据操作的全部命令，可以查看中文网站。
Redis 数据存储格式
Redis 自身是一个 Map，其中所有的数据都是采用 key:value 的形式存储。
对于这种结构来说，我们用来存储数据一定是一个值前面对应一个名称，我们通过名称来访问后面的值，而下面的数据类型，则是修饰 value 的。
string（字符串）
string 介绍
1）存储的数据：单个数据。是最简单的数据存储类型，也是最常用的数据存储类型。
string 就是存一个字符串，注意是 value 那一部分是一个字符串，它是 redis 中最基本、最简单的存储数据的格式。
2）存储数据的格式：一个存储空间保存一个数据。
每一个空间中只能保存一个字符串信息。
3）存储内容：通常使用字符串。如果字符串以整数的形式展示，可以作为数字操作使用。
一个 key 对一个 value，而这个 itheima 就是我们所说的 string 类型，当然它也可以是一个纯数字的格式。
string 基本操作
# 添加/修改数据
set key value
# 获取数据
get key
# 删除数据
del key
# 判定性添加数据
setnx key value
# 添加/修改多个数据
mset key1 value1 key2 value2 …
# 获取多个数据
mget key1 key2 …
# 获取数据字符个数（字符串长度）
strlen key
# 追加信息到原始信息后部（如果原始信息存在就追加，否则新建）
append key value
单数据操作与多数据操作的选择之惑：set 与 mset 的关系
这对于这两个操作来说，要根据各自的特征去比对你的业务，看看究竟适用于哪个。
假如说我们的业务服务器要向 redis 要数据的，它会发出一条指令，那么当这条指令发过来的时候，比如说是这个 set 指令过来，它会把这个结果返回给你，这时我们就要思考这里边一共经过了多长时间。
-
首先，发送 set 指令要时间，这是网络的一个时间，接下来redis要去运行这个指令要消耗时间，最终把这个结果返回给你又有一个时间，这个时间又是一个网络的时间，那我们可以理解为：一个指令发送的过程中需要消耗这样的时间.
-
但是如果说现在不是一条指令了，你要发 3 个 set 的话，还要多长时间呢？对应的发送时间要乘 3 了，因为这是三个单条指令,而运行的操作时间呢，它也要乘 3 了，但最终返回的也要发 3 次，所以这边也要乘 3 。
-
于是我们可以得到一个结论：单指令发 3 条它需要的时间，假定他们两个一样，是 6 个网络时间加 3 个处理时间，如果我们把它合成一个 mset 呢，我们想一想。
-
假如说用多指令发 3 个指令的话，其实只需要发一次就行了。这样我们可以得到一个结论，多指令发 3 个指令的话，其实它是两个网络时间加上 3 个 redis 的操作时间，为什么这写一个小加号呢，就是因为毕竟发的信息量变大了，所以网络时间有可能会变长。
那么通过这张图，我们可以得到一个结论，我们单指令和多指令他们的差别就在于你发送的次数是多还是少。当你影响的数据比较少的时候，你可以用单指令，也可以用多指令。但是一旦这个量大了，你就要选择多指令了，他的效率会高一些。
string 扩展操作
数值增加：
# 语法
incr key
incrby key increment
incrbyfloat key increment
# 示例
127.0.0.1:6379> set num 1
OK
127.0.0.1:6379> incr num
(integer) 2
127.0.0.1:6379> incrby num 5
(integer) 7
127.0.0.1:6379> incrbyfloat num 1.1
"8.1"
数值减少：
decr key
decrby key increment
数据有效期：
setex key seconds value # 该key仅活seconds秒
psetex key milliseconds value # 毫秒单位
string 注意事项
- 数据操作结果返回：
表示运行结果是否成功：
(integer) 0 → false 失败
(integer) 1 → true 成功
表示运行结果值：
(integer) 3 → 3 3个
(integer) 1 → 1 1个
-
数据未获取到时，对应的数据为（nil），等同于 null 。
-
数据最大存储量：512 MB
-
string 在 redis 内部存储默认就是一个字符串，当遇到增减类操作 incr、decr 时会转成数值型进行计算。
-
按数值进行操作的数据，如果原始数据不能转成数值，或超越了 redis 数值上限范围，将报错。
-
redis 所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响。
string 应用场景与 key 命名约定
string 的应用场景在于：主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量。
我们来思考一下：这些信息是不是你进入大 V 的页面以后就要读取这些信息的，那这种信息是一定要存储到我们的 redis 中的，因为它的访问量太高了。那这种数据应该怎么存呢？我们来一块儿看一下方案！
解决方案：
- 在 redis 中为大 V 用户设定用户信息，以用户主键和属性值作为 key，后台设定定时刷新策略即可。
eg: user:id:3506728370:fans → 12210947
eg: user:id:3506728370:blogs → 6164
eg: user:id:3506728370:focuses → 83
- 也可以使用 json 格式保存数据。
eg: user:id:3506728370 → {"fans"：12210947，"blogs"：6164，"focuses"： 83}
- key 的设置约定（数据库中的热点数据 key 命名惯例）：
| 表名 | 主键名 | 主键值 | 字段名 | |
|---|---|---|---|---|
| eg1： | order | id | 29437595 | name |
| eg2： | equip | id | 390472345 | type |
| eg3： | news | id | 202004150 | title |
hash（哈希）
hash 基本操作
对象类数据的存储如果具有较频繁的更新需求操作会显得笨重！
比如说前面我们用以上形式存了数据，如果我们用单条去存的话，它存的条数会很多。但如果我们用 json 格式，它存一条数据就够了。问题来了，假如说现在粉丝数量发生变化了，你要把整个值都改了。但是用单条存的话就不存在这个问题，你只需要改其中一个就行了。这个时候我们就想，有没有一种新的存储结构，能帮我们解决这个问题呢。
如上图所示：单条的话是对应的数据在后面放着。仔细观察：我们看左边是不是长得都一模一样啊，都是对应的表名、ID 等的一系列的东西。我们可以将右边红框中的这个区域给他封起来。
那如果要是这样的形式的话，如下图，我们把它一合并，并把右边的东西给他变成这个格式，这不就行了吗？
这个图其实大家并不陌生，第一，你前面学过一个东西叫 hashmap 不就这格式吗？第二， redis 自身不也是这格式吗？这就是我们要讲的第二种格式：hash 。
在右边对应的值，我们就存具体的值，那左边儿这就是我们的 key。问题来了，那中间的这一块叫什么呢？这个东西我们给他起个名儿，叫做 field 字段。那么右边儿整体这块儿空间我们就称为 hash，也就是说 hash 是存了一个 key:value 的存储空间。
hash 类型
新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息。
需要的存储结构：一个存储空间保存多个键值对数据。
hash 类型：底层使用哈希表结构实现数据存储。
如上图所示，这种结构叫做 hash，左边一个 key，对右边一个存储空间。这里要明确一点，右边这块儿存储空间叫 hash，也就是说 hash 是指的一个数据类型，他指的不是一个数据，是这里边的一堆数据，那么它底层呢，是用 hash 表的结构来实现的。
值得注意的是：
- 如果 field 数量较少，存储结构会优化为类数组结构。
- 如果 field 数量较多，存储结构会使用 HashMap 结构。
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
hash 拓展操作
# 获取哈希表中所有的字段名或字段值
hkeys key
hvals key
# 设置指定字段的数值数据增加指定范围的值
hincrby key field increment
hincrbyfloat key field increment
hash 注意事项
-
hash 类型中 value 只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为 (nil) 。
-
每个 hash 可以存储 232-1 个键值对。hash 类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但 hash 设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将 hash 作为对象列表使用。
-
hgetall 操作可以获取全部属性，如果内部 field 过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈。
hash 应用场景
应用场景：
双 11 活动日，销售手机充值卡的商家对移动、联通、电信的 30 元、50 元、100 元商品推出抢购活动，每种商品抢购上限 1000 张。
解决方案：
也就是商家有了，商品有了，数量有了。最终我们的用户买东西就是在改变这个数量。那这个结构应该怎么存呢？
- 以商家 id 作为 key
- 将参与抢购的商品 id 作为 field
- 将参与抢购的商品数量作为对应的 value
- 抢购时使用降值（incre 负数）的方式控制产品数量
注意：实际业务中还有超卖等实际问题，这里不做讨论。
List（列表）
list 类型
前面我们存数据的时候呢，单个数据也能存，多个数据也能存，但是这里面有一个问题，我们存多个数据用 hash 的时候它是没有顺序的。而我们平时的操作，实际上数据在很多情况下都是有顺序的，那有没有一种能够用来存储带有顺序的这种数据模型呢？list 就是专门来干这事儿。
-
数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分。
-
需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序。
-
list 类型：保存多个数据，底层使用双向链表存储结构实现。
先来通过一张图，回忆一下顺序表、链表、双向链表。
list 对应的存储结构是什么呢？就是 key 存一个 list 这样的结构。
来看一下，因为它是双向的，所以其左边右边都能操作，对应的操作结构两边都能进数据，这就是链表的一个存储结构。那么往外拿数据的时候怎么拿呢？通常是从一端拿，当然另一端也能拿。如果两端都能拿的话，这就是个双端队列，两边儿都能操作。如果只能从一端进一端出，就是栈。
list 基本操作
# 添加/修改数据
lpush key value1 [value2] ……
rpush key value1 [value2] ……
# 获取数据
lrange key start stop
lindex key index
llen key
# 获取并移除数据
lpop key
rpop key
list 扩展操作
# 移除count个value
lrem key count value
# 移出并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
# 如果列表为空，返回一个 nil 。否则，返回一个含有两个元素的列表，第一个元素是被弹出元素所属的 key ，第二个元素是被弹出元素的值。
blpop key1 [key2] timeout # 单位为秒
brpop key1 [key2] timeout
# 从列表中取出最后一个元素，并插入到另外一个列表的头部； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
# 如果列表为空，返回一个 nil 。否则，返回一个含有两个元素的列表，第一个元素是被弹出元素所属的 key ，第二个元素是被弹出元素的值。
brpoplpush source destination timeout
list 类型数据操作注意事项
- list中保存的数据都是string类型的，数据总容量是有限的，最多232 - 1 个元素(4294967295)。
- list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
- 获取全部数据操作结束索引设置为-1
- list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载
list 应用场景
应用场景：
企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？
解决方案：
怎么做呢？建立起 redis 服务器。当他们需要记日志的时候，全部发给 redis。等到想看的时候，通过服务器访问 redis 获取日志，就会得到一个完整的日志信息。这依靠什么来实现呢？就依靠我们的 list 模型的顺序来实现。进来一组数据就往里加，谁先进来谁先加进去，它是有一定的顺序的。
-
依赖 list 的数据具有顺序的特征对信息进行管理。
-
使用队列模型解决多路信息汇总合并的问题。
-
使用栈模型解决最新消息的问题。
set（集合）
set 类型
-
新的存储需求：存储大量的数据，在查询方面提供更高的效率。
-
需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询。
-
set 类型：与 hash 存储结构完全相同，仅存储键，不存储值 (nil)，并且值是不允许重复的。
通过这个名称，基本上能够认识到和我们 Java 中的 set 完全一样。当我们要存储大量的数据，并且要求提高它的查询效率时，用 list 这种链表形式，它的查询效率是不高的，那怎么办呢？hash 表的结构就非常得好，但 set 做了这么一个设定：把 hash 的存储空间给改一下，右边原来存数据的全部存空，数据放到原来的 filed 的位置，这个模型就是我们的 set 模型。
set 类型与 hash 存储结构完全相同，仅存储键，不存储值 (nil)，并且值是不允许重复的。
set 基本操作
# 添加数据
sadd key member1 [member2]
# 获取全部数据
smembers key
# 删除数据
srem key member1 [member2]
# 获取集合数据总量
scard key
# 判断集合中是否包含指定数据
sismember key member
# 随机获取集合中指定数量的数据
srandmember key [count]
# 随机获取集中的某个数据并将该数据移除集合
spop key [count]
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
set 注意事项
-
set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份。
-
set 虽然与 hash 的存储结构相同，但是无法启用 hash 中存储值的空间。
set 应用场景
应用场景：
- 黑名单
资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术，快速获取信息，尤其是个别特殊行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售，例如第三方火 车票、机票、酒店刷票代购软件，电商刷评论、刷好评。
同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用。
ps：爬虫不一定就做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量。
- 白名单
对于安全性更高的应用访问，仅仅靠黑名单是不能解决安全问题的，此时需要设定可访问的用户群体， 依赖白名单做更为苛刻的访问验证。
解决方案：
-
基于经营战略设定问题用户发现、鉴别规则。
-
周期性更新满足规则的用户黑名单，加入 set 集合。
-
用户行为信息达到后与黑名单进行比对，确认行为去向。
-
黑名单过滤 IP 地址：应用于开放游客访问权限的信息源。
-
黑名单过滤设备信息：应用于限定访问设备的信息源。
-
黑名单过滤用户：应用于基于访问权限的信息源。
常用指令
在这部分中涉及两个知识点，一个是对 key 的常用指令，一个是数据库的常用指令。
key 操作分析：
-
key 是一个字符串，通过 key 获取 redis 中保存的数据。
-
对于 key 自身状态的相关操作，例如：删除、判定存在、获取类型等。
-
对于 key 有效性控制相关操作，例如：有效期设定、判定是否有效、有效状态的切换等。
-
对于 key 快速查询操作，例如：按指定策略查询 key 。
key 基本操作
# 删除指定key
del key
# 获取key是否存在
exists key
# 获取key的类型
type key
key 扩展操作
# 排序
sort key
# 改名
rename key newkey
renamenx key newkey
时效性控制相关：
# 为指定key设置有效期
expire key seconds
pexpire key milliseconds
expireat key timestamp
pexpireat key milliseconds-timestamp
# 获取key的有效时间
ttl key
pttl key
# 切换key从时效性转换为永久性
persist key
查询模式：
# 查询key
keys pattern
查询模式规则：
*表示匹配任意数量的任意符号?配合一个任意符号[]匹配一个指定符号
| 查询模式 | 说明 |
|---|---|
| keys * | 查询所有 |
| keys it* | 查询所有以it开头 |
| keys *heima | 查询所有以heima结尾 |
| keys ??heima | 查询所有前面两个字符任意，后面以heima结尾 |
| keys user:? | 查询所有以user:开头，最后一个字符任意 |
| keys u[st]er:1 | 查询所有以u开头，以er:1结尾，中间包含一个字母s或t |
数据库指令
key 重复问题
假如十个人同时操作 redis，会不会出现 key 名字命名冲突的问题？
一定会，为什么？因为 key 是由程序而定义的。你想写什么就写什么，那在使用的过程中大家都在不停地加，早晚有一天会冲突的。
那这个问题我们要不要解决？要！怎么解决呢？我们最好把数据进行一个分类，除了命名规范我们做统一以外，如果还能把它分开，这样是不是冲突的机率就会小一些了，这就是下面要说的解决方案。
Redis 为每个服务提供有 16 个数据库，编号从 0 到 15 ，每个数据库之间的数据相互独立。
这里边需要注意一点，他们这 16 个共用 redis 的内存。没有说谁大谁小，也就是说数字只是代表了一块儿区域，区域具体多大未知。这是数据库的一个分区策略。
数据库操作
在 redis.conf 中，数据库数量的配置项如下：
# 使用 select 加上数据库的下标就可以选择指定的数据库来使用，下标从 0 开始
127.0.0.1:6379> select 15
OK
127.0.0.1:6379[15]>
# 数据移动
move key db
# 数据总量
dbsize
# 数据清除
flushdb
flushall
