中 基础
Redis Pipeline#
一句话答案#
Pipeline 将多个命令打包一次发送，减少网络往返次数（RTT），批量操作性能提升数倍。
核心要点
工作原理对比：
正常模式（N 条命令 = N 次 RTT）：
Client → CMD1 → Server → Response1 → Client RTT 1
Client → CMD2 → Server → Response2 → Client RTT 2
...
Client → CMDN → Server → ResponseN → Client RTT N
Pipeline 模式（N 条命令 = 1 次 RTT）：
Client → [CMD1, CMD2, ..., CMDN] → Server
Server → [Response1, Response2, ..., ResponseN] → Client性能提升： 网络延迟 1ms 时，1000 条命令的 RTT 开销从约 1s 降到约 1ms（再加执行时间）；除了省 RTT，还把多次 read()/write() 系统调用合并成少数几次，官方文档称单服务器 QPS 随批量增大最高可到不用 Pipeline 时的约 10 倍。
关键限制：
| 限制 | 说明 |
|---|---|
| 非原子 | 只是批量传输优化，命令间无事务保证 |
| 不回滚 | 某条命令失败不影响其他命令执行 |
| Cluster 限制 | 不能跨节点，需先按 slot 算出目标节点，再按节点分组分别发送（同一节点上的不同 slot 可放在同一批） |
| 内存缓冲 | 一次不宜太多命令，服务端回复会占用输出缓冲区，建议每批几百到几千条 |
Pipeline vs 事务 vs Lua 脚本：
| 特性 | Pipeline | MULTI/EXEC 事务 | Lua 脚本 |
|---|---|---|---|
| 原子性 | ❌ | ❌（不支持回滚） | ✅ |
| 网络优化 | ✅ 核心优势 | ✅ 一次提交 | ✅ 服务端执行 |
| 条件逻辑 | ❌ | ❌ | ✅ if/else |
| 跨 slot | 同节点可以，跨节点 ❌ | ❌（需 Hash Tag） | ❌（需 Hash Tag） |
| 适用场景 | 批量读写无依赖 | 简单多命令打包 | 需要原子 + 逻辑判断 |
面试回答（2分钟版）
Redis Pipeline 是一种批量发送命令的优化机制。正常情况下客户端每发一条命令就要等待服务端返回，一来一回就是一次 RTT 网络往返。如果要执行 1000 条命令就是 1000 次 RTT，在网络延迟较高时性能瓶颈非常明显。Pipeline 的做法是将多条命令打包一次性发送给服务端，服务端按顺序执行后将结果一次性返回，把 1000 次 RTT 压缩成 1 次，批量操作的吞吐量可以提升数倍甚至数十倍。但有几个关键点要注意：Pipeline 不是原子的，它只是批量传输优化，命令之间没有事务保证，某条命令失败不会影响其他命令的执行也不会回滚。在 Redis Cluster 模式下 Pipeline 不能跨节点执行，需要按 slot 算出目标节点、按节点分组后分别发送。另外一次 Pipeline 不宜打包太多命令，否则服务端的回复占用大量内存缓冲区，一般建议每批控制在几百到几千条。如果需要原子性应该用 Lua 脚本。
追问与易错
追问方向：
- “Pipeline 和事务的区别？”→ Pipeline 只是批量传输优化，命令间无原子性保证，某条失败不影响其他；事务（MULTI/EXEC）保证命令顺序执行但也不支持回滚；需要原子性应用 Lua 脚本
- “Pipeline 命令数量有限制吗？”→ 没有硬性上限，但一次打包太多命令会占用服务端输出缓冲区大量内存，建议每批控制在几百到几千条，避免内存暴增和网络超时
- “Pipeline 可以跨 Cluster 节点吗？”→ 不可以，Pipeline 中的命令必须发往同一个节点；Cluster 模式下需按 slot 找到目标节点、按节点分组，将命令分别 Pipeline 到对应节点执行（Pipeline 本身不要求同 slot，这点和 MULTI/EXEC、Lua 不同）
易错点：
- ❌ Pipeline 是原子的——不是，只是批量发送
- ❌ Pipeline 中某条失败会回滚——不会