Redis Pipeline 通过减少网络往返次数提升 List 队列的吞吐能力，适用于生产者批量写入或消费者批量读取场景。使用 Pipeline 需控制单次批次大小，避免阻塞 Redis 单线程处理其他请求。
先说结论：Pipeline 能显著降低网络延迟对高并发队列的影响，但无法解决队列空等待问题，且需注意批次大小防止阻塞 Redis。
- 先定位：确认瓶颈是网络 RTT 还是 Redis 服务端处理耗时。
- 先做：在客户端启用 Pipeline 批量发送 LPUSH 或 RPOP 命令。
- 再验证：监控客户端发送延迟与 Redis 慢日志，确认无单线程阻塞。
命令速用版
以下 Python redis-py 示例展示如何在生产者端使用 Pipeline 批量写入 List 队列：
import redis
r = redis.Redis(host='localhost', port=6379)
pipe = r.pipeline()
for i in range(100):
pipe.lpush('my_queue', 'item_' + str(i))
pipe.execute()消费者端同样可批量 RPOP，但需注意若队列空时 RPOP 不阻塞，需配合循环或改用 Lua 脚本。
为什么会这样
高并发下 List 队列阻塞通常源于网络往返耗时累积，而非 Redis 处理速度慢。Redis 是单线程模型，每个命令都需要一次网络请求和响应，高并发时网络 RTT 成为瓶颈。Pipeline 允许客户端一次性发送多个命令，服务端一次性返回结果，将 N 次往返减少为 1 次，从而提升吞吐。
分步处理
1. 选择支持 Pipeline 的客户端库，如 redis-py、Jedis、go-redis。
2. 设置合理的批次大小，建议从 50 到 200 之间开始测试，避免单次包体过大。
3. 在代码中包裹批量操作，生产者用 LPUSH，消费者用 RPOP 或 Lua 脚本批量弹出。
4. 增加错误处理，Pipeline 执行失败需支持重试或记录丢失数据，防止数据不一致。
5. 监控 Redis 内存，Pipeline 会在服务端缓冲命令，过大批次可能引发内存尖峰。
怎么验证是否生效
1. 客户端监控：统计单位时间内成功入队/出队数量，对比优化前后吞吐变化。
2. 网络监控：使用 tcpdump 或客户端埋点，确认网络请求次数是否随批次增加而减少。
3. 服务端监控：执行 redis-cli `--latency` 查看延迟波动，检查 slowlog 是否有耗时命令。
4. 资源监控：观察 Redis 内存使用曲线，确认无异常尖峰。
常见坑
1. 原子性误解：Pipeline 不保证原子性，中间失败不会回滚，需业务层补偿。
2. 阻塞风险：单次批次过大可能阻塞 Redis 单线程，影响其他客户端请求。
3. 内存溢出：客户端或服务端缓冲大量数据可能导致 OOM，需限制批次上限。
4. 阻塞命令兼容：BRPOP 等阻塞命令不适合直接放入 Pipeline，需单独处理或改用 Lua。
常见问题
Pipeline 能保证多个 List 操作的原子性吗？
不能。Pipeline 仅减少网络往返，不提供事务原子性，需使用 MULTI/EXEC 或 Lua 脚本保证原子性。
使用 Pipeline 会阻塞 Redis 主线程吗？
会。Redis 处理 Pipeline 中的命令时仍按顺序执行，若批次过大或含慢命令，会阻塞后续请求。
消费者如何使用 Pipeline 配合 BRPOP？
BRPOP 是阻塞命令，不适合直接批量放入 Pipeline。建议改用 Lua 脚本一次性弹出多个元素，或循环 RPOP 配合 Pipeline。
参考来源
Redis Official Documentation - Pipelining
URL: https://redis.io/docs/manual/pipelining/