
案发场景: 你在开发一个内容社区 App。产品经理要求做一个'24 小时热门动态榜单'。 排名规则极其苛刻:不仅仅看浏览量,还要看点赞数和评论数。并且权重不同:浏览算 1 分,点赞算 5 分,评论算 10 分。
你的绝望:
如果用 MySQL:ORDER BY (views * 1 + likes * 5 + comments * 10) DESC。在百万级数据表里跑这种带数学计算的排序,索引直接失效,数据库当场熔断。
如果写 Java 代码:把所有数据捞到内存里排序?OOM(内存溢出)警告。
破局之道:
把浏览量、点赞数、评论数分别存进 3 个 Redis Sorted Set(有序集合)。
然后,祭出大杀器 ZUNIONSTORE,告诉它三个集合的权重(1, 5, 10)。Redis 会用底层的 C 语言,在毫秒级自动帮你计算出总分并生成一个全新的排行榜。
1. 核心原理解剖:什么是 ZUNIONSTORE?
ZUNIONSTORE 是 Redis 有序集合(ZSet)提供的一个并集计算命令。它的强大之处不在于'合并',而在于它的'聚合(Aggregate)'与'加权(Weights)'机制。
官方语法:
ZUNIONSTORE destination numkeys key [key ...][WEIGHTS weight [weight ...]][AGGREGATE SUM|MIN|MAX]
原理解析:
- 多维度数据打散: 你的业务有多项指标(如:阅读、点赞、收藏)。你把每一项指标作为一个独立的 ZSet。ZSet 的
Member是文章 ID,Score是该指标的数量。 WEIGHTS(加权乘法): 核心魔法。你可以为每个 ZSet 指定一个乘数。Redis 在合并前,会把对应 ZSet 里的所有 Score 乘以这个权重。AGGREGATE(聚合逻辑): 当同一个文章 ID 出现在多个 ZSet 时,分数怎么处理?默认是SUM(相加),也支持MIN和MAX。destination(结果落地): Redis 不会把计算结果直接吐给网络,而是极其聪明地存入一个新的 ZSet(目标 Key)中。后续你只需要对这个新 Key 执行ZREVRANGE,就能光速分页获取榜单。
2. 三大硬核实战场景
场景一:综合热度排行榜 (多维度加权计算)
这就是文章开头的场景。
- 数据准备:
zset:views(阅读量)zset:likes(点赞量)zset:comments(评论量)
- 执行计算: 阅读权重 1,点赞权重 5,评论权重 10。
ZUNIONSTORE zset:hot_rank 3 zset:views zset:likes zset:comments WEIGHTS 1 5 10 AGGREGATE SUM


