sdiffstore 比 sdiff 快在省去网络传输与客户端序列化开销，直接在服务端完成差集计算并写入目标 key，仅返回整数结果；其性能优势源于避免将大量数据（如 5–10 万 id）传回客户端再丢弃。
SDIFFSTORE 比 SDIFF 快在哪？
直接结论：用 SDIFFSTORE 替代 SDIFF 做集合差集，能显著降低客户端带宽压力和序列化开销，尤其当差集结果很大时——不是 Redis 服务端变快了，而是你省掉了把几万条数据从服务端拉到客户端再丢弃的那一步。
典型场景是定时任务里计算「今天新增但昨天没出现过的用户 ID」，结果可能有 5–10 万条。用 SDIFF 会把全部 ID 返回给客户端，而多数情况下你只是想存进另一个 key 做后续处理或缓存。
-
SDIFF key1 key2 key3：返回所有差集成员，走网络 + 客户端解析 + 可能被 GC -
SDIFFSTORE destkey key1 key2 key3：差集直接在服务端算完写入destkey，只返回一个整数（写入数量） - Redis 服务端内部执行逻辑几乎一样，差别全在响应阶段
SDIFFSTORE 的 key 顺序不能错
差集是「第一个 key 减去后面所有 key 的并集」，顺序反了结果就完全不对——这不是 bug，是定义如此。比如 SDIFFSTORE res A B C 算的是 A − (B ∪ C)；如果写成 SDIFFSTORE res B A C，那就是 B − (A ∪ C)，语义彻底变了。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 常见错误：把「基准集合」当成最后一个参数，比如误写
SDIFFSTORE res B C A，以为是「A 相对于 B 和 C 的差集」 - 调试技巧：先用
SDIFF A B C在 redis-cli 里跑一遍，确认结果符合预期，再换SDIFFSTORE - 如果基准集合是动态拼接的，务必在代码里加注释强调顺序，比如
// SDIFFSTORE res base_set exclude_set1 exclude_set2
目标 key 被覆盖前不加保护
SDIFFSTORE 会直接覆写 destkey，没有原子性检查、没有 exists 判断、也不支持 XX 或 NX 修饰符。如果那个 key 正在被其他逻辑读取（比如另一个服务正用 SRANDMEMBER 抽样），就会读到中间态或空数据。
- 风险点：定时任务凌晨跑
SDIFFSTORE hot_users today_set yesterday_set，而实时接口每秒都在SMEMBERS hot_users—— 极短时间里可能返回空结果 - 稳妥做法：用临时 key +
RENAME，例如SDIFFSTORE hot_users_tmp today_set yesterday_set，再RENAME hot_users_tmp hot_users（RENAME是原子的） - 注意：
RENAME在集群模式下不支持跨 slot，如果hot_users和hot_users_tmp不在一个 slot，得改用RENAMENX配合重试，或者干脆用带 hash tag 的 key 名，比如hot_users:{tag}和hot_users_tmp:{tag}
大数据量下内存和超时要一起看
SDIFFSTORE 是阻塞命令，服务端得一次性加载所有参与运算的 set 到内存里做哈希比对。如果某个 key 有上百万成员，不仅耗时长，还可能触发 client timeout 或 Redis 的 timeout 配置中断连接。
- 现象：客户端报错
Connection closed by server或READONLY You can't write against a read only replica（其实是主节点卡住，从节点切主失败） - 查证方法：用
MEMORY USAGE keyname看各输入 key 占多少内存，总和超过 500MB 就得警惕 - 折中方案：拆成多轮小差集，比如先把
today_set和yesterday_set差出一批，用SSCAN分批处理；或者改用SET+PFADD做概率去重，不强求精确差集
差集逻辑越靠近 Redis 服务端，越容易忽略它的内存压力和原子性边界——不是命令不够快，是你没看见它背后加载的那些 key 全都进了内存。
