2024.1.8 关于 Redis 数据类型 Zset 集合命令、编码方式、应用场景

[Zset 集合命令](#Zset 集合命令)

[Zset 编码方式](#Zset 编码方式)

[Zset 应用场景](#Zset 应用场景)

引言

在 Redis 中集合间操作无非就是交集、并集、差集

Set 类型与之相对应的操作命令为 sinter、sunion、sdiff

注意：

从 Redis 6.2 版本开始，Zset 命令才开始支持 zinter、zunion、zdiff 这几个命令

但是此处我们使用的是 Redis 5 版本，所以下文不涉及介绍这三个命令

Zset 集合命令

ZINTERSTORE

用于求出给定有序集合中元素的交集，并将其保存进目标有序集合中

合并过程中以元素为单位进行合并，元素对应的分数按照不同的聚合方式和权重得到新的分数

语法：
复制代码
zinterstore destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE <sum | min | max>]
destination：表示要把结果存储到哪个 key 对应的 zset 中

numkeys：描述了后续有几个 key 参与交集运算，因此该变量需为整型

weight：可理解为权重 ，此处指定的权重，相当于一个系数，会乘以当前的分数

aggregate：指定当前给定的有序集合应采用哪种聚合方式来得出新的分数

注意：

前面介绍的命令也是支持多个 key 的，如mget、mset 等

但这些命令却不涉及到类似于此处的设定，即需手动指出 key 的个数

官方文档解释：

主要是为了避免 zinterstore 命令的选项和 keys 弄混淆

即通过 numkeys 描述出 key 的个数后，便可明确知道后面的 "选项" 是从哪里开始的

总结：

正因为 mget、mset 等命令，在指定 keys 后无复杂的选项

所以无需采用 numkeys 来手动指出 key 的个数，以便知道 key 和选项之间的分界处

时间复杂度：

O(N) + O(M * logM)

N 为所有输入命令中总的有序集合元素个数

M 为结果集的元素个数

实例理解

此处我们可以指定权重

我们还可以指定聚合方式

ZUNIONSTORE

用于求出给定有序集合的并集，并将其保存到目标有序集合中

合并过程中以元素为单位进行合并，元素对应的分数按照不同的聚合方式和权重得到新的分数

语法：
复制代码
zunionstore destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE <sum | min | max>]
zunionstore 和 zinterstore 命令的用法大致相同

时间复杂度：

O(N) + O(M * logM)

N 为所有输入命令中总的有序集合元素个数

M 为结果集的元素个数

实例理解

此处我们可以指定权重

我们还可以指定聚合方式

Zset 编码方式

有序集合的内部编码有两种

ziplist（压缩列表）

skiplist（跳表）

注意点一：

如果有序集合中的元素个数较少，或者单个元素体积较小时

使用 ziplist 来存储，以达到节省空间的效果

注意点二：

如果有序集合中的元素个数较多，或者单个元素体积非常大时

使用 skiplist 来存储

两个配置项

zset-max-ziplist-entries：（单位为元素个数）

zset-max-ziplist-value：（单位为字节）

当有序集合的元素个数小于 1号配置项，当每个元素的值都小于 2号配置项时

Redis 会使用 ziplist 来作为有序集合的内部编码

关于跳表

简单来说，跳表是一个复杂链表，其查询元素的时间复杂度为 O(logN)

相比于树形结构，更适合按照范围获取元素（B+ 树）

Zset 应用场景

排行榜系统

微博热搜、游戏天梯排行、成绩排行等

关键要点：

用来排行的分数为实时变化的

虽然是实时变化的，却也能够高效的更新排行

重点理解：

有序集合（zset）能很好的满足上述需求和关键要点

实例理解

比如游戏天梯排行

只需要将玩家信息和该玩家所对应的分数给放到有序集合中即可

从而便能自动就形成一个排行榜

我们也能随时按照排行（下标）、按照分数来进行范围查询

随着分数发生改变，也可以比较方便的使用 zincrby 命令来修改分数，且排行榜顺序也能自动进行调整，该操作的时间复杂度为 O(logN)

问题：

游戏玩家这么多，此时都用这个 zset 来存，内存能否存下？

举例：

假设此时我们有 1亿个玩家

约定 userId 4个字节 ，score 8个字节，即一个玩家需要 12 个字节来表示

12亿字节 ------> 1.2 GB，对于当今计算机来说，绰绰有余！

实例理解二

相较于游戏排行榜，其排序依据很容易确定，仅需根据玩家积分即可

微博的排行榜，其排序依据评估起来更为复杂，因为微博热度是一个综合数值！

其参考方面包含浏览量、点赞量、转发量 、评论量等

上述各方面具有不同权重 weight，进而计算得到综合数值（热度）

重点理解

此时可以借助 zinterstore / zunionstore 命令，按照加权方式进行处理

可以把上述每个维度的数值均放到一个有序集合中

member 为微博的id，score 为各自维度的数值

通过 zinterstore / zunionstore 命令将上述有序集合按照约定好的权重，进行集合间运算即可

最终得到结果集合，其分数便为热度，且排行榜也顺带着出来了！

总结：

上述应用场景，Redis 中的 zset 是一个选择，但不是说非得用 Reids 中的 zset 不可

有些场景下确实可以使用到有序集合，但又不方便使用 Redis 时，可以考虑使用其他方式的有序集合