
Redis 单条命令很快，内存里跑完往往是微秒级。但你在应用里 `for` 循环一百次 `GET`，耗时经常是毫秒甚至几十毫秒。瓶颈通常不在 Redis，在 **每一条命令都要打一个来回**：请求出机房、等响应、下一条才能发。往返次数一多，网络把内存数据库拖成了「远程慢存储」。

管道（Pipeline）要解决的就是这件事：命令照样一条条在 Redis 里执行，但路上少跑几趟。
# 一、什么是 Redis 管道技术？

**Redis 管道技术（Pipeline）**，就是客户端提供的一种批处理技术，把多条命令 **先写进缓冲区，一起发给 Redis，再按发送顺序把回复一次性读回来**。用于一次处理多个 Redis 命令，从而提高整个交互的性能。

管道是**客户端侧**的传输优化 —— 把 N 条命令打包成一次 TCP 请求批量发给 Redis，再一次性读回全部响应，核心收益是砍掉 N−1 次网络往返（RTT）。
Redis 基于 RESP 协议，普通模式下每发一条命令就要等一次往返：
- **普通模式**：发命令 → 等响应 → 再发下一条。N 条命令 = N 个 RTT，串行等待。
- **管道模式**：客户端把命令攒进 socket 写缓冲，一次性 flush 出去；服务器按到达顺序逐条执行，响应集中读回。N 条命令 ≈ 1 次发送 + 1 次响应

# 二、 Redis 管道技术有什么用？
管道技术解决了多个命令集中请求时造成网络资源浪费的问题，加快了 Redis 的响应速度，让 Redis 拥有更高的运行速度。但要注意的一点是，管道技术本质上是客户端提供的功能，而非 Redis 服务器端的功能。
## 收益估算
（设单命令服务端执行时间 t，RTT 为网络往返）：
- 普通模式：`T ≈ N × (RTT + t)`
- 管道模式：`T ≈ RTT + N × t + RTT`
当 RTT 远大于 t（跨机房、异地部署）或 N 很大时，提速接近 **N 倍**。这也是为什么高 RTT 环境（如云上多地域）收益最明显。

## 典型场景
- **批量读：** 商品详情要拼价格、库存、标题，几十个 key，命令类型还不完全一样，不方便一条 `MGET` 搞定。
- **批量写：** 缓存预热、活动开始前灌一批 `SET` / `HSET`，不关心中间每一条的返回再决定下一条。
- **混杂命令：** 一批里既有 `GET` 又有 `INCR`、`EXPIRE`，没有对应的 `M*` 命令可合并。
- **减少系统调用：** 即使用户和 Redis 很近，一百次 `write`+`read` 也比一次大包更亏。
## 限制（必须知道）
- 非原子，无回滚，中途某条失败后续命令照常执行；
- 命令间有依赖（下一步要用上一步结果）时，不能使用
- 一条命令能覆盖场景不要使用，例如 `MGET` 一百个 key，通常比一百条 `GET` 的管道更干净，也少一截协议头。
- 单批不要过大（如几万条），会占满服务端输入缓冲、拖慢网络，建议 100～500 条一批；
- 响应与提交顺序一一对应，消费时别错位。
# 三、 Redis 管道技术怎么用？
##  Jedis
```java
try (Jedis jedis = jedisPool.getResource()) {
    Pipeline p = jedis.pipelined();
    p.set("k1", "v1");
    p.get("k1");
    p.incr("counter");
    List<Object> replies = p.syncAndReturnAll();
    // replies 顺序和上面写入顺序一致：OK、v1、递增值
}
```
# 四、Pipeline和Lua脚本
[Lua是什么以及为啥在Redis中使用Lua？](https://cloud.tencent.com/developer/article/2706313) 
| | | |
|:-:|:-:|:-:|
|对比维度|管道 Pipeline |Lua脚本（EVAL）|
|原子性|否，命令间可穿插其他客户端请求|是，整个脚本原子执行|
|网络往返|N 条 ≈ 1 次发送 + 1 次响应|1 次请求；EVALSHA 只传哈希更省|
|服务端逻辑|无，每条命令独立执行|支持条件、循环、读改写（read-modify-write）|
|命令间依赖|不支持，响应要等回客户端才能用|支持，脚本内直接用上一步结果|
|服务端阻塞|不阻塞其他客户端，命令排队执行|脚本执行期间阻塞（禁死循环、脚本要短）|
|失败处理|无回滚，已执行不撤销，后续照常|中途报错即终止，已写不自动回滚（非事务语义）|
|结果形态|N 个响应，与提交顺序一一对应|单一脚本返回值|
|复用与治理|一次性拼装，无复用|SCRIPT LOAD + EVALSHA 缓存复用；Redis 7 Functions|
|典型场景|批量写/删/查、批量初始化缓存|扣库存防超卖、限流、分布式锁、幂等校验|

**怎么选。**
- 一百个互不相干的 `GET`/`SET`，只要快 —— **管道**（能 `MGET` 就 `MGET`）。
- 必须「看到的库存就是扣掉的库存」，中间不能被别人改 —— **Lua**（或单条原子命令），不要用管道假装原子。
- 既要原子、又有一批无关 key —— 原子那段用 Lua，无关批量用管道，不要揉成一种机制。

Redis 单条命令很快，内存里跑完往往是微秒级。但你在应用里 for 循环一百次 GET，耗时经常是毫秒甚至几十毫秒。瓶颈通常不在 Redis，在 每一条命令都要打一个来回：请求出机房、等响应、下一条才能发。往返次数一多，网络把内存数据库拖成了「远程慢存储」。

Redis 很快，为什么循环 GET 还是慢——Redis系列(十一)

后端

Redis管道技术通过客户端将多条命令打包成一次TCP请求发送，减少N-1次网络往返（RTT），大幅提升批量操作性能，尤其在高RTT或命令量大时提速接近N倍。适用于批量读写、缓存预热等无依赖场景，但非原子且不支持命令间依赖，建议单批100-500条。与Lua脚本对比，管道侧重吞吐，Lua保证原子性，两者可组合使用。

代码解释

数据库

服务器

Redis

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis 很快，为什么循环 GET 还是慢——Redis系列(十一)-腾讯云开发者社区-腾讯云

Redis 很快，为什么循环 GET 还是慢——Redis系列(十一)

Redis 很快，为什么循环 GET 还是慢——Redis系列(十一)

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐