Set集合在分布式状态管理中是轻量、可靠、可扩展的关键工具，凭借唯一性、无序性、高效集合运算三大特性，适用于去重、关系建模与最终一致性聚合场景。
Set 集合在分布式状态管理中不是“拿来即用”的通用容器，而是凭借其唯一性、无序性、高效集合运算三大特性，在特定状态场景下成为轻量、可靠、可扩展的关键工具。它不替代状态协调服务（如 ZooKeeper 或 Etcd），但在去重、关系建模、最终一致性聚合等环节能显著降低复杂度和延迟。
去重型状态：避免重复注册与冗余记录
分布式系统中常需维护“某类事件只发生一次”的语义，比如用户登录、设备上线、任务触发等。若多个节点并发上报，直接写入数据库易产生重复状态。
- 用 Redis Set 存储已处理的唯一标识（如 user_id + timestamp、task_id + shard_id），插入前用
SADD判断是否已存在；返回值为 1 表示首次写入，可安全执行后续逻辑。 - 相比数据库唯一索引，Set 的 O(1) 插入+判断开销更低，且天然支持跨节点共享——所有节点查同一 key 即可达成一致视图。
- 注意：需配合过期策略（
EXPIRE）清理历史状态，否则长期累积可能引发内存压力；也可用带时间戳的 G-Set 思路，将“是否发生过”转为不可删的确定性事实。
关系型状态：关注、好友、权限组的动态建模
用户间的关系（如关注列表、粉丝列表、角色权限集）本质是成员归属关系，天然契合 Set 的数学定义。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个用户 ID 对应一个 Set key（如
user:follow:1001），添加/删除关注即SADD/SREM；查询全部关注者用SMEMBERS，判断是否互相关注可用SINTER求交集。 - 共同好友、兴趣标签匹配等分析类需求，可直接用
SINTER、SUNION、SDIFF在毫秒级完成，无需拉取全量数据到应用层计算。 - 这类状态通常读多写少，且对强一致性要求不高（允许秒级延迟），Redis Set 的高性能与原子性操作完全满足需求。
聚合型状态：计数器、在线统计与增量同步
当需要统计“有多少个节点参与了某件事”，或合并多个来源的状态快照时，Set 提供比累加更鲁棒的方案。
- 分布式计数场景（如文章阅读量）：各节点生成唯一 token（如 UUID + 节点 ID），统一
SADD到全局 key；最终数量由SCARD返回，天然去重，避免网络重试导致的重复计数。 - 在线用户统计：各服务实例将活跃 session ID 写入同一个 Set；中心服务定时
SMEMBERS获取当前全量在线用户，比轮询各节点接口更简单可靠。 - G-Set 类思想可延伸：若需支持“下线后自动剔除”，可在应用层结合心跳机制 + TTL 自动驱逐，而非依赖 Set 本身删除能力。
注意事项与边界提醒
Set 不是万能状态存储，使用时需明确其定位与限制：
- 不支持元素排序（除非用 SortedSet），也不保留插入顺序；需顺序时应选 LinkedHashSet 或额外维护索引。
- 单个 Set 容量虽大（42 亿），但实际应控制在百万级以内，避免
SMEMBERS全量拉取引发网络与内存压力；高频查询建议搭配SRANDMEMBER或分页扫描。 - Redis Set 是最终一致性模型，不提供事务回滚或跨 key 原子操作；涉及多 Set 联动变更（如关注同时更新粉丝），需用 Lua 脚本封装保证原子性。
- Java 中的 HashSet/TreeSet 等本地 Set 仅适用于单机状态缓存，跨进程共享必须依赖 Redis、Etcd 等外部存储，不能混淆使用层级。
