必须用pipeline分批执行，因单条sadd每次需完整rtt，1000次即1000次等待；需显式调execute、控制每批500–2000条、应用层先去重。
直接结论：高并发下向 Redis Set 批量添加数据，必须用 pipeline，但不能无脑堆条数；关键在分批控制、显式执行、应用层去重。
为什么单条 sadd 在高并发下会拖垮性能
每调一次 r.sadd('myset', 'a')，客户端就发一个 TCP 包，等 Redis 回一个响应，再发下一个——哪怕数据只有几个字节，RTT（往返延迟）也卡在毫秒级。1000 次 sadd 就是 1000 次网络等待，不是 CPU 或 Redis 处理慢，是“等”慢的。
常见错误现象：
- QPS 上不去，监控显示 Redis CPU 很低但延迟飙升
- 客户端日志频繁出现 ConnectionResetError 或 TimeoutError
- 同一进程里多个线程共用一个 Redis 实例，sadd 调用互相阻塞
解决思路不是换命令，而是换通信模式：把 N 次请求压缩成 1 次发出去。
pipeline 的正确写法和必须踩的三个坑
Python redis-py 中最简但最容易错的写法：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
pipe = r.pipeline()
for item in items:
pipe.sadd('myset', item)
pipe.execute() # 这行漏掉，数据根本没进 Redis
容易踩的坑：
-
pipe.sadd()只是往本地缓冲区塞命令，不发包；pipe.execute()才真正触发网络发送——很多人循环里写了sadd却忘了最后这句 - 误以为
r.pipeline(transaction=False)是“关事务”，其实它只是禁用MULTI/EXEC封装，和默认行为一样；真要提速，重点是别用transaction=True增加开销 - 用
with r.pipeline() as pipe:看似安全，但如果中间抛异常且没捕获，__exit__会自动调reset()，导致已排队命令全丢
单次 pipeline 该塞多少条 sadd？
没有固定数字，取决于单条数据长度和可用内存。实测安全区间是 500–2000 条/批：
- 如果
item是短字符串（如 UUID），1000 条/批较稳；超过 5000 条，redis-py序列化时可能吃掉几十 MB 内存 - 如果 value 是 JSON 或带前缀的长 key（如
user:profile:123456789:settings），建议压到 200–500 条/批 - Redis 默认配置中
client-output-buffer-limit normal 1mb 500kb 60，单个 client 返回缓冲超 1MB 会被断连——而sadd响应虽小，但大批量执行后紧跟着scard或smembers就容易触发这个限制 - Java Jedis 更敏感：传 10 万条进
pipeline.sync()，可能直接 OOM 或报Broken pipe
高并发场景下必须前置做的两件事
Pipeline 加速的是“发命令”的效率，不是“去重”或“防重复插入”。Set 虽然天然去重，但 sadd 每次仍要走哈希查找、内存分配、返回结果——大量重复值会让 Redis 白忙活。
- 应用层先做
set(items)去重，再喂给 pipeline；尤其当上游数据来自日志、埋点、MQ 消息时，重复率常超 30% - 不要指望 pipeline 让后续读操作变快：比如
pipe.sadd(...); pipe.scard(...)，scard仍要等整批执行完才发，且不属于同一 pipeline 上下文，无法合并 RTT
最常被忽略的一点：pipeline 不减少连接数，也不缓解连接池耗尽问题。高并发写入时，记得检查连接池配置（如 max_connections）是否够用，否则 ConnectionError: Error 113 connecting to localhost:6379. No route to host. 会先于性能问题暴露出来。
