redis pipeline 将 n 次 rtt 压缩为 1 次，通过客户端缓存命令、一次性发送、服务端顺序执行并批量返回实现；提速源于消除串行等待，而非 redis 变快，跨机房场景可提升 4–8 倍。

Redis Pipeline 通过把多个命令打包成一个 TCP 数据包发出去，服务端顺序执行后再统一返回结果，把原本 N 次网络往返（RTT）压缩为 1 次，直接绕过客户端串行等待的瓶颈。

为什么单次请求会卡在 RTT 上

默认模式下，每条命令都走“发→等→收”流程：客户端发出 SET，必须等到 Redis 返回 OK，才能发下一条。哪怕 Redis 执行只要 0.1ms，一次 RTT 却可能耗时几毫秒甚至几十毫秒（跨机房常见 20–50ms）。1000 条命令，光等待网络就占掉 1000 × RTT —— 这部分时间与 Redis 性能无关，纯属传输开销。

Pipeline 是怎么压缩 RTT 的

它不改变 Redis 服务端执行逻辑（仍是串行），但改变了通信节奏：

Bytesagain Ci Cd Pipeline

生成 GitHub Actions、GitLab CI、Jenkins 的 CI/CD 流水线配置，适用于 Node.js、Python、Go、Docker 项目，支持回滚等配置。

下载

• 客户端不再逐条发、逐条等，而是先把所有命令缓存在内存里
• 调用 execute() 时，一次性把全部命令拼成一个 RESP 协议数据块，通过一次 write() 系统调用发出
• 服务端收到后逐条执行，再把所有响应拼成一个大包，一次 write() 返回
• 客户端一次 read() 就拿到全部结果，省掉中间所有等待

实际效果取决于网络延迟高低

本地回环（127.0.0.1）RTT 约 0.04–0.1ms，Pipeline 加速比约 2–3 倍；跨可用区或跨城部署（RTT ≈ 30ms），1000 条命令可从 30 秒降到 30–50ms，提速 4–8 倍。收益不是来自 Redis 变快，而是让网络延迟“只算一次”。

注意几个关键限制

Pipeline 不是事务，也不提供原子性保障：

• 命令间不能有依赖（比如后一条要用前一条 GET 的结果）
• 不支持 WATCH、EVAL、MULTI/EXEC 等需上下文状态的操作
• 某条命令出错（如语法错误、key 只读），不会中断后续执行，错误信息仅体现在响应列表对应位置
• 批大小建议控制在 500–1000 条以内，过大易触发 client-output-buffer-limit 或客户端内存压力