Java中Redis Pipeline通过批量发送命令减少网络往返，提升性能；使用Jedis需调用pipelined()获取实例、添加命令、再execute()执行并检查返回结果，注意连接复用、分组slot、合理批量及错误处理。
Java 中用 Redis Pipeline 打包命令，核心是绕过“发一条、等一条”的阻塞式通信，把多个命令攒起来一次性发、一起收，把多次网络往返压缩成一次。关键不在命令本身多快，而在减少等待时间——尤其跨机房或高延迟网络下效果最明显。
怎么开启和组织 Pipeline 流程
使用 Jedis 时，调用 pipelined() 获取 Pipeline 实例，所有命令（如 set、hset、incr）都调用对应方法写入缓存队列，此时不发给 Redis，也不执行；最后统一调用 sync() 或 execute() 触发批量发送与执行。
- 推荐用 execute()：返回
List<Object>，能逐个检查每条命令结果（比如某次 hset 失败，对应位置会是异常对象） - sync() 适合只关心是否全部发出、不需返回值的场景，无返回值，失败也不抛异常，需额外监听或日志辅助判断
- 避免在 pipeline 中混用事务（MULTI/EXEC），Pipeline 本身不提供原子性，失败命令不影响后续执行
批量大小要合理，不是越多越好
一次打包 100～1000 条命令较稳妥。太小（如每次 10 条）节省有限；太大（如 10000+）易触发客户端/服务端缓冲区溢出，或导致单次处理耗时过长，阻塞其他请求。
- 实测中，1000 条 hset 在局域网通常耗时 20–50ms；超 5000 条可能因内存暂存响应而明显变慢
- 若操作涉及不同 key pattern，注意 Redis 集群模式下 Pipeline 仅支持同 slot 的命令（否则报 ASK/MOVED 错误），需按 slot 分组再分别 pipeline
- 内存敏感场景下，pipeline.execute() 返回的 List
错误处理不能靠“全成功”假设
Pipeline 中命令是顺序执行、独立成败的。前一条命令报错（比如 key 类型不匹配），后一条照样执行，客户端收到的是混合结果列表，必须主动遍历解析。
立即学习“Java免费学习笔记（深入）”；
- 对每个返回值做 instanceof 判断：正常结果是 String/Long 等，错误是
JedisDataException实例 - 建议配合 try-catch 包裹 execute()，并在 catch 后检查 List 中各元素状态，而非依赖整体异常中断
- 不要用 pipeline 替代事务：需要强一致性请改用 MULTI/EXEC；Pipeline 只优化性能，不保原子性
别忽略连接与资源管理
Pipeline 必须复用同一个 Jedis 连接，否则每 new 一个 Jedis 就开新 socket，失去批量意义。生产环境务必通过 JedisPool 获取连接。
- 从连接池取 jedis → pipelined() → 循环添加命令 → execute() → close pipeline（自动释放）→ return jedis 到池
- 切勿在 pipeline 执行中途调用 jedis.close()，会导致底层 socket 关闭，后续 execute 报 IOException
- 若用 Spring Data Redis，对应的是 RedisTemplate.executePipelined()，传入 RedisCallback 回调，内部已封装连接复用逻辑
