Redis Pipeline 通过合并多次网络往返提升吞吐量，核心是减少RTT而非加速单命令；Jedis中需获取pipeline实例、链式入队、syncAndReturnAll执行；建议每批10–100条，按操作类型控制数量，并配合连接池与并发提交。
Redis Pipeline 能批量提升网络吞吐量，核心不是让单条命令变快，而是把多次网络往返（RTT）压成一次。Redis 命令本身执行极快（微秒级），真正拖慢速度的是来回发请求、等响应的过程。内网 RTT 通常 0.5–2ms，1000 次操作光等网络就耗掉近 1 秒；Pipeline 把这 1000 条打包发出、一次收齐结果，RTT 只算 1 次，总耗时接近「1ms + 所有命令执行时间」。
怎么用 Pipeline 实现高效批量操作
以 Java 的 Jedis 为例，关键三步：获取 pipeline 实例 → 链式入队命令（不发出去）→ 触发同步执行并取结果。
- 调用 jedis.pipelined() 获取轻量级 Pipeline 对象，不占用新连接
- 连续调用 set()、get()、hset()、lpush() 等方法，只是把命令暂存在客户端缓冲区
- 最后调用 syncAndReturnAll() 一次性发送、接收、返回按序排列的结果列表（如 [OK, "Tom", 1, null]）
批量规模要合理，不是越大越好
单次塞 1000 条命令进一个 pipeline，反而容易出问题。实测稳定区间在 10–100 条/批，具体看操作类型：
- 纯写操作（如 set/hset）：建议每批 40–60 条
- 读操作（如 get/hgetall）：建议每批 20–40 条，避免响应体过大触发 client-output-buffer-limit
- 混合操作或值较长：优先按总数据体积控制，单批控制在 1–5KB 内更稳妥
必须搭配连接池和并发提交
Pipeline 本身不解决连接瓶颈。若用单连接串行提交 1000 条，再快也卡在排队上。
- Jedis 连接池的 maxTotal 至少设为业务并发线程数的 2 倍
- 1000 个 key 更新，可拆成 20 批 × 50 条，由多个线程并行 submit
- 避免在 Web 请求线程里同步调用 sync()，推荐用 CompletableFuture 编排异步执行
别混淆 Pipeline 和事务，错误处理要主动
Pipeline 不是原子的：某条命令语法错或类型不匹配（比如对 string 执行 hget），不会中断后续命令，错误只体现在结果列表对应位置（如返回 null 或异常对象）。
- 必须遍历 results 列表，逐个检查是否为预期类型或是否抛异常
- 不要用 pipeline.multi() 误当“强事务”——它会转为 MULTI/EXEC，失去 pipeline 的轻量优势，且无法部分回滚
- 真需要原子性且逻辑简单，优先考虑 Lua 脚本；否则接受“尽力而为”，靠业务层兜底
