有序集合（sorted set）在 Redis 中同时具备成员唯一性和分值排序能力，常被用来维护排行榜、优先级队列和权重列表。当业务上需要把多个有序集合合并成一个新的有序集合并保存下来时，ZUNIONSTORE 是一个不可忽略的命令。它会把多个输入有序集合的并集计算出来，并在服务端直接写入指定的目标键，避免客户端拉取数据后再手动合并。与只返回结果而不落盘的 ZUNION 不同，ZUNIONSTORE 的重点在于存储，因此更适合生成汇总视图或固定快照。
在使用 ZUNIONSTORE 之前，需要先理解它的完整语法以及各个参数对最终分值的影响。很多人容易忽略权重和聚合方式的作用，只把命令当成简单的集合拼接，这会导致计算结果和预期出现偏差。下面从语法结构、权重逻辑、聚合策略以及性能表现几个层面展开说明。
命令语法与参数说明
ZUNIONSTORE 的基本语法如下：
ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight ...] [AGGREGATE SUM|MIN|MAX]
其中 destination 是存储结果的目标键，numkeys 表示参与合并的有序集合数量，后面需要跟对应数量的键名。这个数量参数并不是可有可无的，它能帮助 Redis 明确区分哪些是键名、哪些是可选参数。如果省略 numkeys 或写错，Redis 可能把 WEIGHTS 当成键名解析，从而报错或产生意外结果。
各个参数的具体含义可以用下面的列表概括：
- destination：目标键，结果会写到这里。如果目标键已经存在，新的有序集合会覆盖旧值。
- numkeys：参与运算的有序集合数量，必须与后续提供的键数量一致。
- key [key ...]：一个或多个有序集合键。
- WEIGHTS：可选参数，后面跟与键数量相同的权重值，用于在聚合前对每个有序集合的分值进行乘法运算。默认权重全部为 1。
- AGGREGATE：可选参数，决定多个有序集合中同一成员分值如何合并。可选值为
SUM、MIN、MAX，默认是SUM。
需要注意的是，numkeys 的作用在实际调用中经常被低估。假设要合并 zset1 和 zset2，命令必须写成 ZUNIONSTORE out 2 zset1 zset2。如果写成 ZUNIONSTORE out zset1 zset2，Redis 会尝试把 zset1 解析为数量，导致语法错误。这个设计虽然看起来繁琐，但能避免键名与后续选项参数混淆，是 Redis 有序集合聚合命令的一致约定。
权重、聚合与缺失成员的处理
理解权重和聚合策略是正确使用 ZUNIONSTORE 的核心。权重会在聚合发生之前应用到每个输入有序集合的分值上。比如某个成员在集合 A 中的分值是 10，给集合 A 设置权重 2，那么这个成员在参与聚合时的基础分就变成 20。权重可以灵活调整不同指标的重要性，在综合评分场景中非常实用。
聚合方式决定了来自多个集合的分值如何合并。SUM 会把加权后的分值相加，MIN 取最小值，MAX 取最大值。如果使用 MIN 或 MAX，需要特别留意：只有最终被选中的那个分值才是来源分值，其他分值会被忽略。例如集合 A 中成员 x 加权后分值为 12，集合 B 中成员 x 加权后分值为 8，那么 MIN 结果为 8，MAX 结果为 12。
还有一个容易忽略的细节是缺失成员的处理。对于某个成员，如果它没有出现在某个输入有序集合中，Redis 会将该集合中这个成员的分数视为 0，然后再应用权重和聚合。这意味着并集运算的结果并不总是直观的加法。例如集合 A 中有成员 a 分数为 1，成员 b 分数为 2；集合 B 中有成员 a 分数为 10，成员 c 分数为 20。执行权重 2 和 3 的求和聚合后，a 的结果为 1×2+10×3=32，b 的结果为 2×2+0×3=4，c 的结果为 0×2+20×3=60。可以看到，原本在 B 中不存在的 b 仍然有机会进入结果，只是它的最终分数完全来自 A 的贡献。
下面通过 Redis 命令行演示这个过程：
127.0.0.1:6379> ZADD zset1 1 a 2 b (integer) 2 127.0.0.1:6379> ZADD zset2 10 a 20 c (integer) 2 127.0.0.1:6379> ZUNIONSTORE out 2 zset1 zset2 WEIGHTS 2 3 AGGREGATE SUM (integer) 3 127.0.0.1:6379> ZRANGE out 0 -1 WITHSCORES 1) "b" 2) "4" 3) "a" 4) "32" 5) "c" 6) "60"
从输出可以看到，结果按键值升序返回，成员 b 因为只在一个集合中出现，最终分值较低；成员 a 和 c 则综合了两个集合的加权分值。如果想要让某个输入集合的分数在缺失时不被当成 0，只能通过业务侧预先填充默认值，或者在聚合前使用其他命令补齐数据。
底层执行流程与性能分析
ZUNIONSTORE 的执行并不是简单的键合并，它在服务端内部会先读取所有输入有序集合的成员和分值，然后根据权重与聚合规则计算每个成员的新分值，最后对结果进行排序并写入目标键。整个过程由 Redis 单线程原子完成，因此在执行期间其他客户端请求会被阻塞。对于数据量较大的有序集合，这个阻塞时间可能达到几十毫秒甚至更久。
从时间复杂度来看，ZUNIONSTORE 的复杂度为 O(N×K)+O(M log M)。其中 N 表示输入有序集合中元素数量的较小值或处理过程中的中间元素数量，K 表示输入集合的个数，M 表示最终结果集的元素数量。也就是说，聚合的对象越多、输入集合越大，命令执行时间越长。O(M log M) 部分来自结果排序，Redis 有序集合底层使用跳表和哈希表，写入时也需要维护排序结构。
由于 ZUNIONSTORE 会把结果直接存储到目标键，目标键的旧值会被原子覆盖。在生产环境中，如果目标键原本用于线上读取，覆盖操作会导致短暂的旧数据消失，但不会出现中间状态。为了避免大量写入造成内存压力，可以给结果键设置合理的过期时间，或者使用临时键合并后再重命名。另一个思路是尽量避免在高频请求路径上频繁执行大规模并集运算，可以通过定期离线计算或先缩小输入集合规模来降低阻塞风险。
与只读的 ZUNION 相比，ZUNIONSTORE 增加了存储开销。如果只需要把合并结果返回给客户端而不需要保留，使用 ZUNION 更轻量；如果需要后续继续基于结果做范围查询、分页或再次聚合，那么 ZUNIONSTORE 是更合适的选择。
多维度排行榜合并实战
一个典型的应用场景是将多个维度的评分合并成综合排行榜。例如一个内容平台可能同时维护阅读量排行榜、点赞量排行榜和收藏量排行榜，运营人员希望生成一个综合热度榜。此时可以给三个有序集合分别设置不同权重，例如阅读量权重 0.3、点赞量权重 0.5、收藏量权重 0.2，然后用 ZUNIONSTORE 合并到新的有序集合中。
下面使用 Python 的 redis-py 客户端演示合并过程：
import redis
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
# 初始化三个维度的有序集合
r.zadd('read_rank', {'article1': 1000, 'article2': 800})
r.zadd('like_rank', {'article1': 300, 'article2': 500, 'article3': 200})
r.zadd('fav_rank', {'article1': 50, 'article3': 80})
# 合并到综合热度榜，权重分别为 0.3、0.5、0.2
r.zunionstore(
'hot_rank',
['read_rank', 'like_rank', 'fav_rank'],
weights=[0.3, 0.5, 0.2],
aggregate='sum'
)
# 查看合并结果
print(r.zrevrange('hot_rank', 0, -1, withscores=True))
# 输出：[('article1', 460.0), ('article2', 490.0), ('article3', 116.0)]
从输出可以看出，article2 虽然阅读量低于 article1，但由于点赞权重较高，最终综合分反超 article1。这就是权重设计对结果排序的影响。实际业务中，权重需要根据指标重要性做调整，必要时还要先对原始分数做归一化处理，避免某个维度的数值范围过大而主导整个结果。
在合并完成后，建议使用 ZRANGE 或 ZREVRANGE 快速验证结果是否符合预期，同时也可以通过 ZSCORE 查看特定成员的最终分值。如果结果集的规模很大，还可以结合 EXPIRE 命令给 hot_rank 设置过期时间，让过期后自动重新生成，减轻维护成本。
总之，ZUNIONSTORE 的强大之处在于把多个有序集合的合并、加权、聚合和存储集中到服务端一步完成。理解权重与聚合规则，尤其是缺失成员按 0 处理这一细节，能够帮助开发者避免很多隐藏的分数计算问题，从而更稳定地构建排行榜、汇总视图等业务能力。
Redis ZUNIONSTORE有序集合并集运算修改时间：2026-09-18 07:59:59