SRANDMEMBER 不能真正保证不重复抽中：不带 count 时单次无重复；带正数 count 且超过集合大小时会重复；负数 count 强制有放回；安全不重复抽奖应使用 SPOP 或 Lua 脚本实现原子性抽取。
SRANDMEMBER 能否真正随机且不重复抽中？
不能直接保证不重复，SRANDMEMBER 默认允许重复抽样。它只是从 Set 中“无放回”地随机返回元素，但若指定数量超过 Set 大小，Redis 会自动退化为“有放回”，导致结果可能含重复项。
- 不带 count 参数时（
SRANDMEMBER key），每次返回 1 个元素，绝不会重复——因为单次只取一个，且底层是真随机索引访问 - 带 count 参数（
SRANDMEMBER key 3），若 Set 只有 2 个成员，Redis 会返回 3 个元素，其中至少 1 个必然重复 - 加负号（
SRANDMEMBER key -5）强制启用“有放回”模式，即使 Set 很大，也允许重复——这适合模拟抽奖池可复用的场景（如转盘抽奖）
如何安全实现「不重复」的 N 人随机抽奖？
必须分两步：先确保原子性地移出中奖者，再返回结果。直接靠 SRANDMEMBER + 应用层去重，会在并发下失效——两人可能同时抽到同一人，且都以为自己中奖了。
- 推荐用
SPOP：它原子性地随机弹出并删除 N 个元素，天然不重复，适合一次性开奖（如抽取 5 名幸运用户） - 若需保留原始名单（比如抽奖后还要发通知、记录日志），得用 Lua 脚本封装：
EVAL "local r = redis.call('SRANDMEMBER', KEYS[1], ARGV[1]); redis.call('SREM', KEYS[1], unpack(r)); return r" 1 prize_pool 3 - 注意
SPOP在 Redis 6.2+ 才支持 count 参数；旧版本只能循环调用，性能差且非原子
为什么不用 SMEMBERS + 应用层 shuffle？
看似简单，实则危险。尤其当 Set 成员数达万级时，SMEMBERS 会把全部数据拉到客户端内存，网络和 GC 压力陡增；更关键的是，两次操作（读 + 删）之间存在竞态窗口。
-
SMEMBERS返回的是无序列表，但“无序”不等于“随机”——Redis 内部按哈希桶遍历，顺序不稳定但可预测，某些版本甚至会复现 - 应用层
shuffle()后只删部分元素？得再发 N 条SREM命令，中间若有其他写入，中奖名单就错乱了 - 集群环境下，
SMEMBERS若落在非主节点（只读副本），可能读到过期数据
抽奖结果需要留痕，又不想影响原 Set 怎么办？
别动原 Set，用 SUNIONSTORE 或 SCARD + SRANDMEMBER 配合业务逻辑做隔离。
- 提前用
SUNIONSTORE temp_pool origin_pool拷贝一份（注意：这不是深拷贝，而是新建一个 Set，值相同但键独立） - 对
temp_pool执行SPOP或 Lua 抽奖，抽完直接DEL temp_pool - 如果只是要“查总数+随机看几个”，用
SCARD确认规模，再用SRANDMEMBER key 10查预览——但别把这当最终结果，它不锁定 - 避免用
SSCAN遍历后筛选，游标不保证随机性，且无法控制抽样分布
SPOP，如果抽奖请求峰值远超 QPS 上限，排队延迟会导致用户感知“卡顿”，这时候得前置加限流或异步队列，而不是在 Redis 指令上硬扛。 
