Redis Pipeline 通过批量发送命令并一次性接收响应，减少 N−1 次网络往返（RTT）来加速 SADD/ZADD 批量写入；它非事务，需显式调用 execute()，单次建议≤1000 条，避免 OOM 或缓冲区溢出。
Redis Pipeline 为什么能加速 SADD/ZADD 批量写入
单条 SADD 或 ZADD 命令每次都要走一次网络往返（RTT），哪怕数据很小，延迟也卡在 TCP 往返上。Pipeline 把多条命令打包发过去，服务端顺序执行再一次性回包，省掉中间 N−1 次 RTT —— 这是提速的核心，不是“命令本身变快了”，而是“不等响应就继续塞命令”。
注意：Pipeline 不是事务，失败不会回滚；它只是批量发送+批量接收，每条命令仍独立执行、独立返回结果。
Python redis-py 中正确用法：避免自动 flush 的坑
很多人直接循环调 pipe.sadd() 然后忘掉 execute()，结果数据根本没进 Redis。更隐蔽的坑是用了 pipeline(transaction=False) 却误以为开了事务，其实只是关了 MULTI/EXEC 封装，和默认行为一样。
- 必须显式调用
pipe.execute()才真正发包 - 单次 Pipeline 建议控制在 1000 条以内，太大可能触发客户端内存暴涨或服务端缓冲区拒绝（尤其在高延迟链路）
- 混合使用
SADD和ZADD完全没问题，Pipe 不关心命令类型
pipe = r.pipeline()
for item in items:
pipe.sadd('myset', item)
for score, member in zitems:
pipe.zadd('myzset', {member: score})
pipe.execute() # 这行不能少Java Jedis 的 batch 写入要手动分片
Jedis 默认 pipeline 没有内置分批逻辑，如果你传入 10 万条 SADD，sync() 时会尝试一次性构造超大字节数组，容易 OOM 或触发 Linux TCP 缓冲区限制（如 Broken pipe 错误）。
- 按 500–2000 条为一批调
pipeline.sync()，具体看单条数据长度和可用内存 - 别用
jedis.sadd(String key, String... members)直接传数组做“批量”，它底层仍是单条命令，不走 pipeline -
ZADD在 Jedis 4.x+ 支持Map<String, Double>入参，但依然要放进 pipeline 才有效
什么时候不该用 Pipeline 加速 SADD/ZADD
当你要插入的数据里存在大量重复成员（比如 SADD 重复加同一值），Pipeline 不会帮你去重，反而把冗余请求全发过去，浪费带宽和 CPU。此时应先在应用层 dedup，再喂给 pipeline。
另外，如果插入后立刻要 SCARD 或 ZCOUNT，别指望 pipeline 能让这些读操作也变快——它们得等 pipeline 执行完才能发，且不属于同一 pipeline 上下文。
最常被忽略的一点：Pipeline 不解决连接数瓶颈。如果并发写入来自多个进程/线程，每个都建自己的 pipeline 连接，Redis 的 maxclients 和连接创建开销才是新瓶颈。
