Redis从6.2版本开始，在有序集合（sorted set）命令族中正式加入了ZUNION这条只读型的并集运算命令。在此之前，如果开发者想要计算多个有序集合的并集，只能使用ZUNIONSTORE把结果写入到一个新的目标键中，然后再通过ZRANGE等命令去读取，整个过程既产生了额外的写操作，也占用了新的内存空间。ZUNION的出现改变了这一局面，它直接在命令执行期间于内存中完成合并计算并返回给客户端，不会在数据库中留下任何中间结果。
ZUNION命令的基础语法与参数含义
ZUNION的官方基础语法为：ZUNION numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX] [WITHSCORES]。其中numkeys用于声明后面要参与运算的有序集合键的数量，这个数值必须和实际传入的key个数严格一致，否则Redis会返回错误。与早期的ZUNIONSTORE相比，ZUNION不需要指定destination参数，因为它不写盘也不写库，仅仅承担计算与返回的职责。
WEIGHTS子句允许为每一个参与运算的键设置一个乘法权重。例如第一个键的权重是2，第二个键的权重是3，那么在合并时，第一个键中的成员分数会先乘以2，第二个键中的成员分数会先乘以3，然后再按照AGGREGATE策略聚合。AGGREGATE支持三种模式：SUM表示将各来源分数相加（默认），MIN表示取所有来源中的最小分数，MAX表示取最大分数。当某个成员只存在于部分键中时，缺失键视为分数为0参与运算。
WITHSCORES选项和普通有序集合读取命令一样，会让返回结果不仅包含成员名，也一并返回合并后的分数。如果不加该选项，则只返回成员列表。由于ZUNION是只读命令，它在副本节点上也可以安全执行，不会触发任何复制链上的写同步，这在读多写少的榜单类业务中非常实用。
通过代码示例看ZUNION的实际使用
下面我们用一段Redis CLI与Python代码来演示ZUNION的典型用法。假设我们有两个有序集合，分别是本周游戏排行榜week1和上周排行榜week2，里面存放了玩家和对应的积分。
# 添加测试数据 redis-cli ZADD week1 100 player_a 80 player_b 60 player_c redis-cli ZADD week2 90 player_a 70 player_b 50 player_d # 直接求并集，分数相加，并返回分数 redis-cli ZUNION 2 week1 week2 WITHSCORES
上面的命令会输出player_a为190，player_b为150，player_c为60，player_d为50。这是因为player_a在两个集合都有，分数被求和；而player_c和player_d只在一个集合出现，相当于另一个集合贡献了0分。如果我们只关心谁的分数最高而不想累加，可以改用MAX聚合。
import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
# 使用权重：本周占比0.7，上周占比0.3
result = r.zunion(
{'week1': 0.7, 'week2': 0.3},
aggregate='SUM',
withscores=True
)
for member, score in result:
print(member.decode(), score)
在Python的redis-py客户端里，zunion方法接受字典形式的键值与权重映射，底层就是封装了ZUNION命令。通过给week1和week2设置不同权重，我们轻松实现了加权平均榜，而不必像旧版本那样先ZUNIONSTORE到临时键再做读取。这种写法减少了两次网络往返和一次写操作，对高并发接口非常友好。
ZUNION与ZUNIONSTORE的性能及场景对比
从实现层面看，ZUNION和ZUNIONSTORE在底层都调用了相同的有序集合合并算法，时间复杂度都是O(N*K)+O(M*log(M))，其中N是每个集合的平均大小，K是集合个数，M是结果集大小。真正的差异在于ZUNIONSTORE会把M个结果写入数据库，触发可能的持久化与复制，而ZUNION只是把M个结果组装后发给客户端然后释放。因此在纯粹需要临时视图的场景，ZUNION明显更省资源。
但并不是说ZUNION能完全取代ZUNIONSTORE。如果你的业务要求把合并榜保存下来，供后续多个不同的服务反复读取，或者需要对该结果再次做交集、范围裁剪，那么用ZUNIONSTORE落盘一次仍然是合理选择。另外，在Redis版本低于6.2的环境中，由于根本不存在ZUNION命令，也只能退化使用ZUNIONSTORE配合读取删除的方案。下面的表格简单归纳了二者的适用边界。
| 维度 | ZUNION | ZUNIONSTORE |
|---|---|---|
| 是否写库 | 否 | 是 |
| 最低版本 | 6.2 | 2.0左右 |
| 典型场景 | 临时榜单、接口内计算 | 持久合并、二次运算 |
| 副本压力 | 无写同步 | 有写同步 |
在实际架构中，我们可以把ZUNION放在API层做实时聚合，比如电商网站把“销量榜”和“好评榜”临时融合成综合推荐榜；而把ZUNIONSTORE放在离线任务里，每天凌晨生成“周常总榜”供前台缓存读取。厘清二者差异，才能避免盲目升级写法导致数据丢失或资源浪费。
使用ZUNION时的常见误区与避坑建议
第一个常见误区是忘记写对numkeys。由于ZUNION要求第一个参数明确声明键数量，当开发者用变量拼接命令时，如果变量和实际键数不符，服务端会直接报错，而不是忽略多余键。建议在代码里始终用集合或字典的长度来填充numkeys，不要硬编码数字。
第二个误区是误以为权重可以为负并产生“扣分”效果。虽然Redis允许WEIGHTS填写负数，聚合SUM时确实会减去分数，但如果使用了MIN或MAX聚合，负权重可能导致出乎意料的最小值或最大值，进而让榜单出现负数分数成员排在前面的奇怪现象。除非业务明确需要，否则权重应保持在正数范围，并在测试环境验证聚合结果。
第三个需要留意的点是超大集合的并集。由于ZUNION在运算期间会在内存中生成完整的结果集再返回，如果参与运算的有序集合成员总量达到百万级，一次性返回可能撑爆客户端内存或造成Redis阻塞。此时应考虑分片、使用ZUNIONSTORE落盘后配合ZSCAN游标读取，或者在应用层做分桶合并，而不是强行用一条ZUNION吃掉全部数据。