目录
引言
Zset 集合命令
ZINTERSTORE
ZUNIONSTORE
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 时,可以考虑使用其他方式的有序集合