Pipeline 是 Redis 性能优化里最容易立竿见影的一招。把多条命令攒在一次网络往返里，吞吐量往往能明显提升。
但 Pipeline 优化的是客户端和服务器之间的 RTT，不是命令执行复杂度。你把一批慢命令塞进 pipeline，它们仍然会在主线程上一个个执行。
先把机制边界说清楚
这一篇讨论网络交互和批量发送，不讨论事务语义。Pipeline 不保证原子性，也不等于 MULTI/EXEC。
整体路径
上面这张图先把主线铺开：一次发送多条命令，服务器仍按顺序执行。所以 Pipeline 的代价看的是网络往返和回复缓冲，它不会让单条慢命令变快。
底层机制
- 普通请求是一条命令一次 RTT；Pipeline 把多条命令连续写入连接。
- Redis 仍然按输入顺序解析和执行命令，结果按顺序进入回复缓冲。
- 批次过大时，客户端内存、服务端输出缓冲和网络拥塞都会变成风险。
- 连接池数量、超时和重试策略会直接影响 Redis 的连接压力。
这些机制放在一起看，就能理解 Pipeline 降的是 RTT 不是命令成本——它解决网络问题，不解决慢命令问题。
取舍与边界
Pipeline 的最佳使用方式是小批量、可控返回量、命令成本稳定。无限攒批只是在把延迟和内存风险往后推。
典型问题：用机制化例子排查
- 批量读写设置合理 batch size，不要把十万条命令一次塞进连接。
- Pipeline 中避免混入大返回命令，否则回复缓冲会迅速膨胀。
- 客户端超时后要谨慎重试，命令可能已经在 Redis 侧执行。
- 连接池复用要稳定，避免每次请求新建连接导致握手和 fd 压力。
收束：一句判断
Pipeline 是网络优化，不是复杂度豁免券。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
