Redis ZINTERSTORE 的 WEIGHTS 和 AGGREGATE 怎么组合

我第一次用 Redis 做“多个榜单都出现过的成员重新打分”时，最容易混在一起的是两个参数：WEIGHTS 负责先把每个输入集合的 score 乘上权重，AGGREGATE 负责再把同一成员的多个加权结果合并。它们不是两种互斥写法，而是前后相邻的两步。

实际选择可以先记成一句话：要累加贡献就用 SUM，要取共同认可的最低分就用 MIN，要保留各榜单中最高的一次表现就用 MAX。不写这两个选项时，权重默认都是 1，聚合默认是 SUM。

Redis ZINTERSTORE 的计算顺序是“交集成员筛选 → 各集合 score 乘权重 → 按 AGGREGATE 合并 → 写入目标 Sorted Set”。WEIGHTS 的数量必须和输入 key 数量对应；AGGREGATE 改变的是最终 score，不改变哪些成员能够进入交集。

先把两个榜单放进一个具体场景

假设我有一个“点击热度榜”和一个“质量榜”。两者都只保存成员和分数，成员 go、redis 同时出现，mysql 只在点击热度榜中出现，因此最终交集只能留下前两个成员。

# 先准备两个输入 Sorted Set；分数故意使用不同量纲，方便观察权重变化
redis-cli ZADD clicks 100 go 80 redis 70 mysql
redis-cli ZADD quality 0.8 go 0.9 redis 0.6 python

# 不指定权重和聚合时，Redis 采用权重 1 与 SUM
redis-cli ZINTERSTORE result-default 2 clicks quality
redis-cli ZRANGE result-default 0 -1 WITHSCORES

这里的 result-default 中，go 的结果是 100 + 0.8 = 100.8，redis 的结果是 80 + 0.9 = 80.9。mysql 和 python 因为没有同时出现在两个输入 key 中，不会出现在结果里。

WEIGHTS 是按输入 key 顺序相乘

我在第一次给榜单调权时，曾把权重理解成“最终结果乘一个总系数”。实际上，WEIGHTS 是逐个对应输入 key 的列表：第一个权重乘第一个 key 的 score，第二个权重乘第二个 key 的 score，依次类推。

# clicks 的分数更偏向曝光量，quality 的分数更偏向质量，先把它们拉到想要的相对比例
redis-cli ZINTERSTORE result-weighted 2 clicks quality WEIGHTS 0.01 100
redis-cli ZRANGE result-weighted 0 -1 WITHSCORES

# go = 100*0.01 + 0.8*100 = 81；redis = 80*0.01 + 0.9*100 = 90.8
# 这个结果仍然使用默认 SUM，只是每个输入的贡献已被重新缩放

这也是为什么我习惯把 WEIGHTS 写在命令末尾并与输入 key 同行对照。把两个 key 调换，却不调换两个权重，会得到另一个完全不同的评分模型。权重可以是整数或浮点数，也可以使用负数；负权重会让该榜单的分数反向影响结果，适合表达扣分，不适合在没有说明的情况下直接用于排名。

AGGREGATE 决定交集分数如何合并

为了只观察聚合差异，我把两个输入的权重都固定成 1。对于 go，两个加权分数是 100 与 0.8；对于 redis，它们是 80 与 0.9。同一组输入换不同聚合器，结果就会体现不同的业务判断。

# SUM：累加两个榜单的贡献，适合“多项证据越多越高”
redis-cli ZINTERSTORE result-sum 2 clicks quality WEIGHTS 1 1 AGGREGATE SUM

# MIN：保留较低的一项，适合“短板决定可用性”
redis-cli ZINTERSTORE result-min 2 clicks quality WEIGHTS 1 1 AGGREGATE MIN

# MAX：保留较高的一项，适合“任一榜单突出即可进入候选”
redis-cli ZINTERSTORE result-max 2 clicks quality WEIGHTS 1 1 AGGREGATE MAX

# 统一读取三个结果，方便逐个成员比较 score
redis-cli ZRANGE result-sum 0 -1 WITHSCORES
redis-cli ZRANGE result-min 0 -1 WITHSCORES
redis-cli ZRANGE result-max 0 -1 WITHSCORES

这三个结果可以这样读：SUM 下 go 是 100.8，MIN 下是 0.8，MAX 下是 100；redis 对应是 80.9、0.9、80。聚合器只改变共同成员的最终分数，不会把 mysql 或 python “补进”结果。

我现在会用这个模板检查参数顺序

当命令需要由程序拼接时，我会先把输入 key 和权重写成表格，再生成命令。关键检查点只有三项：目标 key 是否会覆盖旧结果、numkeys 是否等于输入 key 数量、权重数量是否同样等于输入 key 数量。

# 通用模板：destination、numkeys、输入 key、WEIGHTS、AGGREGATE 必须按这个顺序
redis-cli ZINTERSTORE  \
  WEIGHTS  AGGREGATE 

# 这里输入 key 有两个，所以 numkeys 与 WEIGHTS 都各写两个参数
redis-cli ZINTERSTORE ranking:final 2 ranking:clicks ranking:quality \
  WEIGHTS 0.01 100 AGGREGATE SUM

# 目标 key 被重算；读取数量只影响展示，不改变 ZINTERSTORE 的计算
redis-cli ZCARD ranking:final
redis-cli ZRANGE ranking:final 0 9 REV WITHSCORES

ZINTERSTORE 的返回值是写入目标 Sorted Set 的成员数量，而不是总分。需要展示排名时再用 ZRANGE ... REV WITHSCORES 读取；不要把返回的数量误当成聚合结果。

空交集和负权重怎么解释

如果输入集合没有共同成员，结果 Sorted Set 会是空的，返回数量为 0。这不是 SUM、MIN 或 MAX 的差异，而是交集在聚合前就没有候选。我的做法是把“没有结果”当成正常业务状态处理，而不是继续猜测聚合参数。

负权重则需要在业务层明确含义。例如把质量榜权重设为 -1，会让质量分越高，最终的加和越低。它可以做惩罚项，但要同时检查最终排名是否仍然符合“分数越高越靠前”的约定；如果只是想表达不达标成员不能进入结果，往往应该在写入前过滤，而不是用负权重替代过滤。

还要记住，目标 key 是存储位置。重复执行同一个命令会重新写入目标结果，不能把它当作增量叠加。输入集合很大时，官方文档给出的复杂度与最小输入集合、输入集合数量和结果集合规模有关，应该把交集计算放在能接受阻塞时间的路径上，避免把它塞进请求链路的每次实时调用。

最后用一张表做选择

对我来说，最稳的落地顺序是先问“哪些成员必须同时出现”，再问“不同榜单的分数要不要换尺度”，最后才选“贡献、短板还是亮点”。这样就不会把 WEIGHTS 和 AGGREGATE 当成同一个开关。

相关问题

• WEIGHTS 少写一个会怎样？ 应确保权重数量与输入 key 数量对应；不要依赖参数缺失来表达默认值，程序拼接时应显式补齐。
• AGGREGATE 不写时是不是取最大值？ 不是，默认是 SUM。
• 为什么单个榜单独有的成员不在结果里？ ZINTERSTORE 计算的是交集，只有每个输入 key 都存在的成员才会进入候选。
• 能不能只调整最终 Sorted Set 的排序方向？ 可以在读取时用正序或倒序范围命令，但那不会改变 ZINTERSTORE 已经写入的 score。