Redis ZDIFFSTORE 如何计算排行榜差集：成员集合、分值规则与结果集核验

线上做“待处理排行榜”时，最容易把集合方向写反：把已处理成员放在第一个键，结果就会变成另一份清单。ZDIFFSTORE 的规则很明确——以第一个 Sorted Set 为基准，排除后续集合中的成员，并把差集写入目标键；目标键已经存在时会被覆盖。

把候选榜放在第一个参数，已处理榜放在后面；执行后先核对返回数量，再用 ZRANGE WITHSCORES 检查成员和分值。

一次“待处理榜变空”的故障，先看集合方向

假设 rank:candidate 是本批候选，rank:done 是已经发放过奖励的成员。目标是得到仍待处理的成员：

ZADD rank:candidate 100 alice 80 bob 60 carol
ZADD rank:done 100 alice
ZDIFFSTORE rank:pending 2 rank:candidate rank:done
ZRANGE rank:pending 0 -1 WITHSCORES

这里的差集是“rank:candidate 减去 rank:done”，所以 alice 会被排除，bob 和 carol 会留下。若把 rank:done 放在第一个位置，结果就失去了业务含义。

ZDIFFSTORE 的成员与分值分别从哪里来

ZDIFFSTORE destination numkeys key [key ...] 需要先给出参与计算的键数量。第一个 Sorted Set 提供候选成员和它们的分值，后续集合只参与“是否存在”的排除判断。在上面的例子里，bob 的 80 和 carol 的 60 都来自 rank:candidate。

因此，排查结果时要同时执行 ZCARD rank:pending 和 ZRANGE rank:pending 0 -1 WITHSCORES。只有数量对得上、成员来自候选榜、分值也符合候选榜，才说明差集计算真正正确。

把差集落盘后，按覆盖和空结果两条路径验收

ZDIFFSTORE 返回写入结果集的成员数量。它不是“新增了多少成员”，而是本次计算后 destination 中有多少成员。重复执行同一命令时，旧的 rank:pending 会被覆盖，因此验收要关注计算后的完整结果。

ZDIFFSTORE rank:pending 2 rank:candidate rank:done
ZCARD rank:pending
ZRANGE rank:pending 0 -1 WITHSCORES

ZDIFFSTORE rank:pending 2 rank:done rank:candidate
ZCARD rank:pending

第一条命令应留下 bob、carol；第二条命令的基准集合换成了 rank:done，结果可能为空。这里别只看命令没有报错，集合方向和业务预期必须一起复核。

生产环境还要补一层键位与并发检查

目标键是业务可读的中间结果时，建议把生成时间或批次写进变更记录，并在覆盖前确认读端允许看到短暂的旧结果。若多个任务同时刷新同一个 rank:pending，后完成的计算会覆盖先完成的结果，最好让批次使用不同 destination，验收完成后再切换引用键。

Redis Cluster 中，ZDIFFSTORE 访问多个键，相关键需要满足集群多键命令的同槽约束。可以给同一批次的键使用相同 hash tag，例如 rank:{reward}:candidate、rank:{reward}:done 和 rank:{reward}:pending，再用集群客户端实际检查键位；不要仅凭键名相似就认为它们在同一槽。

相关问题

ZDIFFSTORE 会修改输入集合吗？

不会。它读取参与计算的 Sorted Set，把结果写入 destination；输入集合仍保持原样。

差集为空时 destination 会怎样？

计算结果没有成员时，destination 不会保留旧的成员，最终表现为空 Sorted Set 或被删除，应用侧应以返回数量和后续查询共同确认。

可以用 ZDIFFSTORE 做跨槽计算吗？

普通 Redis Cluster 不应假设跨槽多键计算可用。先按集群多键规则安排同槽键位，再执行命令；无法同槽时需要调整数据布局或在应用侧分步计算。

发布前的最小核对清单

先确认第一个键确实是候选集合，再核对 numkeys 与实际键数量一致；命令执行后读取返回数量、ZCARD 和 ZRANGE WITHSCORES，最后检查 destination 覆盖范围及 Redis Cluster 的槽位安排。这样能把“命令成功”与“业务结果正确”分开验收。