案发场景： 你在开发一个内容社区 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
