Redis ZDIFF 怎样只保留第一个有序集合的独有成员

如果你要找出“候选集合里有、但已处理集合里没有”的成员，Redis 的 ZDIFF 可以直接完成这个差集。它把第一个有序集合当作基准，只保留不出现在后续集合中的成员；需要分数时追加 WITHSCORES。最容易出错的地方是把集合顺序写反，或者在 Redis Cluster 中把不在同一槽位的多个 key 直接放进一次命令。

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

记住一个方向：ZDIFF 2 基准集合 排除集合 返回“基准集合减去排除集合”。结果为空是合法业务结果，不等于命令失败。

• 第一个 key 决定候选范围，后续 key 只用于排除成员。
• WITHSCORES 会同时返回保留下来的成员和它们在第一个集合中的分数。
• ZDIFF 返回结果数组，不会创建目标 key；需要落盘时再考虑 ZDIFFSTORE。
• 多 key 操作在 Redis Cluster 中有同槽位要求，不能把这件事当成普通单 key 查询。

先确认差集方向

假设 release:candidates 是待发布成员，release:done 是已经完成的成员。目标是得到“候选但未完成”的集合，基准集合必须放在第一个位置。Redis 官方定义的差集也是以第一个有序集合为基准，排除后续集合中的同名成员。

# 第一个 key 是候选集合，第二个 key 是需要排除的已完成集合
redis-cli ZDIFF 2 release:candidates release:done

# 命令参数中的 2 表示后面紧跟两个有序集合 key
# 下面的调用只读取结果，不会改写这两个集合
redis-cli ZDIFF 2 release:candidates release:done

如果把两个 key 对调，含义就变成“已完成但不在候选中的成员”。这不是 Redis 计算错了，而是差集本身有方向。工程代码中建议把基准 key 和排除 key 分别命名，再由封装函数组装参数，减少调用方凭记忆交换顺序的机会。

用 WITHSCORES 保留结果分数

只需要成员名时，普通 ZDIFF 返回成员列表；如果后续还要按优先级、时间或权重继续处理，就加上 WITHSCORES。返回分数来自第一个有序集合，后续集合只参与“是否排除”的判断。

# 只读取基准集合里没有出现在排除集合中的成员
redis-cli --raw ZDIFF 2 release:candidates release:done

# 同时保留成员和它在基准集合中的 score
redis-cli --raw ZDIFF 2 release:candidates release:done WITHSCORES

不要把返回数组当作哈希表解析。使用客户端库时，应按库的返回类型读取成员和分数；如果自行解析 RESP 结果，则要明确“成员、分数”成对出现的约定。

区分空结果与参数错误

当基准集合的每个成员都出现在后续集合中时，差集为空。这是业务上“没有待处理项”，通常应转成空列表继续流程，而不是立即报警。参数数量错误、key 类型不是 Sorted Set、权限不足或连接中断，才是需要进入错误处理分支的情况。

# 空差集是合法返回：调用方可以把它映射为待处理数量 0
redis-cli --raw ZDIFF 2 release:candidates release:done

# 先检查 key 类型，避免把类型错误误判成“没有差集”
redis-cli TYPE release:candidates
redis-cli TYPE release:done

如果封装层需要统一返回值，可以把结果分为三类：成功且有成员、成功但为空、命令执行错误。这样重试策略只作用于真正的连接或服务错误，不会因为空结果反复请求 Redis。

处理 Cluster 多键边界

ZDIFF 一次读取多个有序集合 key。Redis 官方文档特别提示，这类多键命令在集群环境中的行为与部署方式有关。使用 Redis Cluster 时，应让参与同一次多键运算的 key 通过相同的 hash tag 落到同一槽位，并在客户端或路由层保持命名规则一致。

# 通过同一个 hash tag 让相关 key 使用相同的槽位标签
redis-cli ZADD 'release:{team42}:candidates' 10 build-101
redis-cli ZADD 'release:{team42}:done' 10 build-100

# 两个 key 共享 {team42}，才具备放在同一次集群多键运算中的设计基础
redis-cli ZDIFF 2 'release:{team42}:candidates' 'release:{team42}:done'

这里的 hash tag 只是路由设计，不会改变 ZDIFF 的差集方向。若业务无法保证同槽位，不能靠换一个命令参数解决；可以改成分片后在应用侧合并，或使用 ZDIFFSTORE 时仍按同样的 key 路由约束设计目标 key。

最后检查调用契约

上线前只需要围绕四个问题检查封装：第一个 key 是否真的是基准集合，是否需要 WITHSCORES，空数组是否被当作正常结果，以及 Cluster 下参与运算的 key 是否使用一致的 hash tag。如果结果需要写入 Redis，再单独评估 ZDIFFSTORE 的目标 key 和覆盖语义。

常见问题

ZDIFF 会修改原来的有序集合吗？不会，它返回差集结果；需要存储结果时使用专门的存储命令。

后续集合的分数会影响结果分数吗？不会。后续集合只决定成员是否被排除，保留成员的分数来自第一个集合。

空数组是不是 Redis 出错？不是。只要命令执行成功，空数组表示没有满足差集条件的成员。