登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis Set 怎样计算多个集合的差集

来源:17golang原创

时间:2026-11-07 21:30:38 245浏览 收藏

Redis 计算多个 Set 的差集可直接使用 SDIFF:第一个键是基准集合,后面的所有集合都是排除来源。SDIFF A B C 表示保留 A 中既不在 B、也不在 C 的成员,即 A − (B ∪ C)。需要把结果保存成新集合时,使用 SDIFFSTORE destination A B C。

我更习惯先给键名写清业务角色,再写集合命令。把已完成名单放成第一个参数,即使命令执行成功,也会算出另一种业务结果。差集关系本身简单,真正需要控制的是键名来源、集合新鲜度和结果键的覆盖范围。

Redis 官方地址:https://redis.io/

先确定候选集合和排除集合

以候选任务成员筛选为例,candidates 保存候选,blocked 保存当前不参与的成员,completed 保存已经完成的成员。要保护的资产是输入名单及其业务含义,差集只产生待处理候选,不承担最终授权或任务领取的全部职责。

下面使用同一批次的固定测试键。花括号标签 {sdiff-demo} 为这些键提供相同的哈希标签,适合在采用同槽多键约束的 Redis Cluster 场景组织示例。它只是分槽方式,不会自动提供租户权限。

# 在隔离测试环境中使用未被占用的样例键;先确认不存在,避免混入旧成员
redis-cli EXISTS 'demo:{sdiff-demo}:candidates' 'demo:{sdiff-demo}:blocked' 'demo:{sdiff-demo}:completed'

# 只有确认三个键均未占用后,才建立这组固定示例输入
redis-cli SADD 'demo:{sdiff-demo}:candidates' u17 u28 u39 u40
redis-cli SADD 'demo:{sdiff-demo}:blocked' u28 u99
redis-cli SADD 'demo:{sdiff-demo}:completed' u39 u40

成员都是虚构标识。对于这组输入,u28 被 blocked 排除,u39 与 u40 被 completed 排除,u99 从未进入基准集合,因而不会出现在差集中。剩余成员应为 u17;这是按样例定义推导的结果,不是本机执行记录。

用 SDIFF 直接返回多个集合的差集

# 首键固定为候选集合,后续键全部作为排除来源
redis-cli SDIFF 'demo:{sdiff-demo}:candidates' 'demo:{sdiff-demo}:blocked' 'demo:{sdiff-demo}:completed'
说明差集中的首集合与排除集合关系
静态结构说明图:candidates 是基准集合,blocked 与 completed 都是排除来源;按正文样例,数学差集包含 u17,图不是运行结果。

SDIFF 返回成员,不修改这三个输入集合。Set 没有业务排序保证,调用方不应把返回顺序当成优先级;如果展示需要稳定排序,在应用中显式排序,或另外设计具有顺序语义的数据结构。

这里也不是把多个集合中“只出现一次”的元素都找出来。B 或 C 独有的成员不会自动进入结果;只有第一个集合中的成员才有保留资格。因此,不能为了让参数排列整齐而给所有键名排序。

把错误键名和越界输入挡在业务层

我会把错误分成两类:一类是成员筛选逻辑错误,例如首键错位;另一类是数据边界错误,例如排除集合已过期或键来自另一租户。后者可能让不该进入候选的成员重新出现。

Redis 将不存在的输入键按空集合处理。这意味着排除集合缺失时,命令不一定报错;业务应区分“本批确实没有排除成员”和“排除数据尚未准备好”。可由上游保存批次就绪状态、数据版本或生成记录,而不是只依赖一个键是否存在。

若已有键的类型不是 Set,则应处理类型错误,检查写入方和键名约定,不要通过删除未知键来强行修复。下列命令是给读者的排查示例:

# 查看输入键类型,none 与 set 需要结合业务就绪状态理解
redis-cli TYPE 'demo:{sdiff-demo}:candidates'
redis-cli TYPE 'demo:{sdiff-demo}:blocked'
redis-cli TYPE 'demo:{sdiff-demo}:completed'

对外接口不应直接接收客户端提交的任意 Redis 键列表。由服务器根据已经确认的业务范围生成键名,限制集合数量和候选规模;权限配置应覆盖实际使用的命令和键范围。名单成员也不宜完整写入普通日志,可记录批次、键角色、耗时和结果数量。

需要保存结果时隔离目标键

若后续任务要多次读取结果,可以使用 SDIFFSTORE。它的返回值是结果成员数量,而不是成员列表;查看成员需要另行读取结果集合。

# 使用本次计算专用的结果键,不能填入业务输入键
redis-cli SDIFFSTORE 'demo:{sdiff-demo}:result:run01' 'demo:{sdiff-demo}:candidates' 'demo:{sdiff-demo}:blocked' 'demo:{sdiff-demo}:completed'

# 示例有效期为十分钟;这与上面的存储是两个命令
redis-cli EXPIRE 'demo:{sdiff-demo}:result:run01' 600

# 仅对这份小型测试结果读取全部成员
redis-cli SMEMBERS 'demo:{sdiff-demo}:result:run01'
区分读取输入与保存结果的键边界
静态结构说明图:SDIFFSTORE 读取三个输入集合,写入独立结果键;EXPIRE 管理结果生命周期,两个命令不是一个不可分割操作。

目标键已存在时会被覆盖。因此建议让目标名称包含独立运行标识,并确认它属于当前任务,不与 candidates、blocked 或 completed 共用。固定使用 result:run01 仅为本文演示,真实并发任务应使用各自的运行标识。

SDIFFSTORE 与 EXPIRE 分开执行,不能声称“计算成功就一定有有效期”。若进程在中间退出,清理策略需要覆盖这一缺口;可按业务需要设计受控事务或其他生命周期管理。本例保持最短命令路径,但没有把它包装成完整并发调度器。

记录计算依据并判断结果边界

检查对象判断重点可记录的信息
第一个集合是否为真正的基准候选角色与批次
后续集合是否都应作为排除来源数据版本与就绪状态
结果写入目标键是否独立且可覆盖运行标识与清理策略
结果消费是否还要重新判断业务条件领取或处理的最终状态

一次差集命令只针对执行时可见的集合状态。命令结束后名单仍可能被其他请求修改;若下一步是发放资格或领取任务,需要在真正改变业务状态的位置维护一致性,不能将之前读到的候选永久当成授权结论。

官方命令复杂度按所有输入集合的成员总量计为 O(N)。大集合会带来计算和返回数据成本,保存结果也会占用存储空间;别把一次命令等同于没有成本。应使用真实业务规模评估延迟,不为教程虚构性能数据。

交换 B、C 会影响结果吗?

在输入内容不变的前提下,两者都是排除来源,交换不改变数学结果;交换 A 与其中任一个则改变基准。

SDIFF 会把候选集合里的成员删掉吗?

不会。它只返回差集;SDIFFSTORE 会写目标键,所以目标键应与输入分开。

可以用差集表示允许访问的用户吗?

可以作为名单计算的一部分,但最终访问决定还要考虑权限更新、数据就绪、租户边界与实际操作时的一致性。缺少排除集合不应被默认为业务允许。

官方参考:SDIFF、SDIFFSTORE、Redis Set。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>