Redis 的 Pipeline 功能是什么？
- 标签：后端、Redis
🏛 业务架构师
Pipeline（管道）让客户端把一批命令打包、一次网络往返发送，服务端按序执行、批量返回——消灭的是每条命令一个 RTT 的网络成本。
业务账：跨机房 RTT 2ms，逐条执行 100 个 hget 要 200ms+ 网络；Pipeline 打包后 2ms+ 微量执行时间——两个数量级的延迟差。场景：
- 商品详情页聚合渲染需要 30 个缓存键 → 一次 mget/Pipeline；
- 批量初始化/预热缓存、批量设置过期；
- 一次业务判断要读多个独立 key（用户信息+配置+计数）。
必须讲清的三个语义边界（误用即事故）：
- 不是原子的：Pipeline 只是打包传输，执行中间可以被其他客户端命令插入——需要"批量原子"用 Lua 或 MULTI。见过把 Pipeline 当事务用导致数据错乱的；
- 不是事务的：部分失败没有回滚，每条命令独立成败，结果要逐条检查；
- 阻塞风险：一次打包几十万命令等于长时间占用单线程的 Redis——批要限量（经验：单批 500~1000 条 + 分批迭代），大 key 大批是"一条 Pipeline 打挂一个集群"的真实案例。
架构层的组合建议：Cluster 模式下 Pipeline 的命令必须同 slot（或客户端按 slot 分组打包——Lettuce/Redisson 自动做了分组，选客户端时要确认这个能力）；高频固定组合的 key 用 hash tag 聚槽是常见手段，但要评估热点代价。
一句话：Pipeline 是网络成本的优化，语义上什么都没承诺——用它提速，别用它保正确。
🏗 系统架构师
Pipeline 是 Redis 的批量提交协议优化：客户端把多条命令打包，一次网络往返发送，Redis 依序执行后打包返回结果。
解决什么：Redis 单条命令执行微秒级，但每次请求一个 RTT（同机房 0.5~1ms，跨机房几 ms）——1 万条命令逐条发就是 10 秒以上，瓶颈全在网络。Pipeline 把 N 次 RTT 压成 1 次，吞吐提升 10~100 倍。
关键特性（必须讲清的边界）：
- 非原子、非事务：只是网络层打包，命令之间可插入其他客户端请求；需要原子性用 MULTI/Lua；
- 不减少 Redis 执行成本，只省网络——命令本身耗时不变，太多命令一次涌入会阻塞其他客户端（建议每批 100~1000 条，分批 submit）；
- Cluster 模式下命令必须路由到同一节点（按 slot 分组分别 pipeline）。
与相关机制对比：
- mget/hmget 等批量命令：服务端原生批量，一个命令搞定，优先用；
- Lua：多命令 + 原子 + 逻辑编排；
- pipeline：多命令 + 省网络，无原子性。
我的实践：批量初始化缓存（预热数千 key）、批量查询（循环内收集命令一次执行）、数据迁移同步工具，都是 pipeline 的典型场景；配套监控每次 pipeline 的批大小与耗时，防止"一批发 10 万条"阻塞生产实例。
💻 全栈开发专家
Pipeline = 客户端把一批命令打包、一次网络往返发送，服务端按序执行后批量返回结果，解决的是 RTT（往返延迟） 问题。
java
// 10 万个 key 初始化：逐条 10 万次 RTT vs pipeline 批量
redisTemplate.executePipelined((RedisCallback<Object>) conn -> {
for (int i = 0; i < 100000; i++) {
conn.stringCommands().set(("k:" + i).getBytes(), "v".getBytes());
}
return null; // 结果在回调外统一拿
});我实测：本机逐条 10 万 set 约 10s，pipeline（每批 1000）压到 300ms——快几十倍不是因为 Redis 算得快，是省了网络往返。
三个必须知道的边界：
- 不是原子的：命令只是排队执行，中间可能穿插其他客户端命令——需要原子用 Lua/MULTI；
- 不是事务的：某条失败其余照常执行，无回滚；
- 分批控制：一次塞几十万条会把服务端输出缓冲区打爆（client output buffer 满直接断连），我按 500~1000 条一批；注意集群模式下 pipeline 命令会分发到多节点，跨 slot 命令报错，需要客户端按 slot 分组（Redisson/Lettuce 已处理）。
适用判断：批量读写、预热、初始化、批量删除（配合 scan）——凡是"很多条互不依赖的命令"都值得 pipeline。