Redis ZUNIONSTORE 的 COUNT 聚合排名设计

如果多个 Redis 有序集合都记录了同一批成员，而你想知道“一个成员出现在多少个集合里”，不必先把数据读到应用层再计数。ZUNIONSTORE 配合 AGGREGATE COUNT，可以直接把成员出现的集合数量写成结果有序集合的 score，再用 ZREVRANGE 读取降序排名。

本文围绕三个主题集合演示这个设计：zset:topic:go、zset:topic:redis 和 zset:topic:db。这里的 score 只作为输入有序集合的原始字段存在；使用 COUNT 后，原始 score 不再参与求和，结果 score 表示成员出现于多少个输入集合。

官方地址：https://redis.io/docs/latest/commands/zunionstore/

最小可用命令是 ZUNIONSTORE 结果键 输入集合数量 输入键... AGGREGATE COUNT。不指定 WEIGHTS 时，每个包含该成员的输入集合贡献 1 分；最终按结果 score 倒序读取即可得到“出现次数排名”。

先把“COUNT”理解成成员出现次数

Redis sorted set 是由唯一 member 和对应 score 组成的有序集合。假设三个集合中有如下成员：

# 这里只展示输入数据关系；每个集合的原始 score 不用于 COUNT 求和
zset:topic:go     user:101=10, user:102=8
zset:topic:redis  user:101=7,  user:103=9
zset:topic:db     user:101=6,  user:102=5, user:103=4

user:101 出现在三个集合中，user:102 出现在两个集合中，user:103 也出现在两个集合中。因此 COUNT 聚合后的分数应该是 3、2、2。输入 score 是 10、7、6 还是其他数值，不会改变 COUNT 的计数结论。

最小写法：指定三个输入集合和 COUNT

命令中的第二个参数是输入集合数量，必须与后面紧跟的输入键数量一致。把结果写入 rank:topic:count 的最小写法如下：

# 将三个主题集合按成员出现次数合并到排名键
redis-cli ZUNIONSTORE rank:topic:count 3 \
  zset:topic:go zset:topic:redis zset:topic:db \
  AGGREGATE COUNT

# 返回结果集合中的成员数量，再读取全部成员和分数
redis-cli ZREVRANGE rank:topic:count 0 -1 WITHSCORES

这里的 3 不是排名条数，而是输入 key 的数量。AGGREGATE COUNT 告诉 Redis：对每个出现在输入集合中的 member，按“出现在哪些集合里”计算结果 score。命令成功后会覆盖同名的目标键，因此目标键适合当作一次计算得到的派生排名，不要把它误当作需要保留人工写入的原始集合。

分层检查：结果 score 为什么不是原来的分数

排查排名不符合预期时，先看是否把默认的 SUM 和 COUNT 混在了一起。SUM 会累加成员在输入集合中的 score；MIN 和 MAX 会分别选择最小或最大 score；而 COUNT 会忽略原始 member score，按成员出现的输入集合数量计分。

例如三个集合的数据关系对应的 COUNT 结果可以整理成：

如果你看到的结果像 23、13、13 这样的数值，通常说明命令实际使用的是默认 SUM，或者客户端没有把 AGGREGATE COUNT 传到 Redis。排查时先检查发送给 Redis 的完整命令字符串，再检查结果键是否确实是本次计算生成的键。

WEIGHTS 什么时候会改变 COUNT 的含义

不带 WEIGHTS 时，每个包含 member 的集合贡献 1。带上权重后，COUNT 仍然不读取原始 score，但每个输入集合的贡献值会变成对应的 weight，最终 score 是这些贡献值的总和。

# 不同主题集合有不同业务权重；COUNT 统计的是加权出现次数
redis-cli ZUNIONSTORE rank:topic:weighted 3 \
  zset:topic:go zset:topic:redis zset:topic:db \
  WEIGHTS 3 2 1 AGGREGATE COUNT

# 按加权结果从高到低读取成员和分数
redis-cli ZREVRANGE rank:topic:weighted 0 -1 WITHSCORES

在这个例子里，成员同时出现在 go 和 redis 集合中时，COUNT score 是 3+2=5；只出现在 db 集合中时是 1。因此，带权重的结果已经不是“集合数量”本身，而是“集合存在性贡献的加权和”。如果需求只是统计覆盖集合数，就省略 WEIGHTS，避免调用方误解分数。

反向验证：用 ZREVRANGE 读取排名

排名通常是分数越高越靠前，所以使用 ZREVRANGE。下标从 0 开始，0 -1 表示读取整个结果集；只要前十名时可以改成 0 9。加入 WITHSCORES 才能同时看到成员和 COUNT 分数。

# 读取前 10 名，同时保留出现次数，便于组装响应
redis-cli ZREVRANGE rank:topic:count 0 9 WITHSCORES

# 只需要成员时省略 WITHSCORES，但会丢失排名依据
redis-cli ZREVRANGE rank:topic:count 0 9

多个成员拥有相同 score 时，Redis 会按 member 的字典序排列。同分状态下如果产品还需要时间、用户等级等二级排序，不能把 COUNT score 当成唯一排序依据，应在应用层补充稳定的二次排序，或者把复合排序规则设计成另一种数据模型。

出现异常时按四层检查

1. 检查版本：Redis 官方命令文档记录 AGGREGATE COUNT 从 Redis 8.8.0 开始提供。如果服务端版本较旧，先确认命令语法是否支持，不要只看客户端是否能构造参数。
2. 检查输入类型：所有输入键都应是 sorted set。把普通 set、hash 或字符串键混进来，会得到类型错误；把不存在的键当作空集合处理时，也要确认这是否符合业务预期。
3. 检查目标键：目标键会被结果覆盖。若目标键恰好也是输入键之一，先把原始数据复制到独立的输入键，避免把派生结果覆盖后又参与下一次计算。
4. 检查多键边界：命令一次读取多个键。在 Redis Cluster 场景中，多键命令还要遵守集群对 key 所在槽位的要求；如果客户端返回跨槽错误，优先调整 key 命名和槽位设计，不要把错误归因于 COUNT 聚合。

一张表记住参数含义

结论

ZUNIONSTORE ... AGGREGATE COUNT 适合把“成员覆盖了多少个集合”直接转换成可排序的 score。无权重时每个集合贡献 1，带权重时变成按集合贡献加权；结果键是可重建的派生数据，并且会覆盖已有同名键。完成聚合后，用 ZREVRANGE ... WITHSCORES 读取降序排名，最后再根据同分成员的字典序规则补充业务层的二次排序。

相关问题

• ZUNIONSTORE 的 COUNT 和默认 SUM 有什么区别？
• Redis ZUNIONSTORE 的 WEIGHTS 如何影响 COUNT 分数？
• 如何只读取 COUNT 聚合后的前十名？
• Redis Cluster 执行多键 ZUNIONSTORE 为什么会跨槽？