Redis管道通过攒批命令一次性发送并统一接收响应，减少网络往返，提升性能6–8倍；Jedis中调用pipelined()获取Pipeline，链式调用命令入队，最后用sync()或syncAndReturnAll()执行。
Java 中用 Redis 管道（Pipeline）批量执行多条命令，核心是**把多个命令攒起来一次性发出去，再统一收响应**，避免每条命令都等一次网络往返（RTT）。它不改变命令逻辑，也不保证原子性，但能显著提速——实测 1000 条 SET/GET 操作，比逐条快 6–8 倍。
基本使用步骤（以 Jedis 为例）
主流 Java 客户端如 Jedis、Lettuce 都支持 Pipeline，Jedis 最常用，写法最直观：
- 调用 jedis.pipelined() 获取一个 Pipeline 实例（非阻塞，不立即发命令）
- 链式调用命令方法，如 pipe.set("k1", "v1")、pipe.get("k2")，这些操作只是入队，不触发网络通信
- 最后必须显式调用 pipe.sync() 或 pipe.syncAndReturnAll() 才真正发送并等待响应
- sync() 返回 void，适合只关心执行成功与否的场景；syncAndReturnAll() 返回 List<Object>，按发送顺序一一对应结果（比如第 3 个 get() 的返回值在列表索引 2 的位置）
代码示例：批量设值 + 批量取值
下面是一个完整可运行的片段：
Jedis jedis = new Jedis("localhost", 6379);
try (Pipeline pipe = jedis.pipelined()) {
// 批量写入
for (int i = 0; i < 1000; i++) {
pipe.set("user:" + i, "name" + i);
}
// 批量读取
for (int i = 0; i < 1000; i++) {
pipe.get("user:" + i);
}
// 一次性执行，获取全部响应
List<Object> results = pipe.syncAndReturnAll();
// 前1000个是SET结果（通常为"OK"），后1000个是GET结果
}
jedis.close();
关键注意事项
Pipeline 不是“加了就快”的银弹，用错反而出问题：
立即学习“Java免费学习笔记（深入）”；
- 不保证原子性：某条命令报错（比如对 string 类型执行 HGET），其余命令照常执行，错误只体现在结果列表对应位置（如 null 或异常对象），需遍历检查每个响应
- 响应顺序严格匹配发送顺序：不能靠 key 名匹配结果，必须按索引取值。例如第 5 个 pipe.get("abc") 的结果一定在 results.get(4)
- 避免单次打包过大：建议每批控制在 100–500 条。超 1000 条易触发 Redis 输出缓冲区限制（默认 client-output-buffer-limit）或 TCP 分包，导致连接断开
- 不能有执行依赖：禁止在 pipeline 中先 get 再根据结果决定是否 set——这类分支逻辑必须拆到 pipeline 外单独处理
和事务（Transaction）的区别
有人会混淆 Pipeline 和 Multi/Exec 事务：
- Pipeline 是通信优化，只减少网络次数，命令仍独立执行，失败互不影响
- Transaction 是语义保障，用 multi/exec 包裹后，Redis 会把所有命令排队、串行执行，并在 exec 时统一返回结果（但依然不回滚已执行成功的命令）
- 两者可结合：先用 pipeline 发送 multi → 一堆命令 → exec，但一般没必要；更常见的是「纯 pipeline」或「纯 transaction」，按需选择
