管道是什么
管道把多条命令一次性写入连接、再统一读回响应，把 N 次网络往返摊薄成 1 次。关键点在于：服务端仍然逐条执行，管道不提供事务语义，也不改变任何单条命令的复杂度，收益完全在往返次数与系统调用层面。批量多大要压测校准，批次越大，批内最后一条的等待越久。
基本信息
| 层级 | 客户端与连接复用层面 |
|---|---|
| 收益 | 减少 RTT 与 write/read 系统调用 |
| 不做的事 | 不提供原子性、不跨命令回滚 |
| 命令工具 | redis-cli --pipe 按协议批量灌入 |
| 调优 | 批次大小按网络与延迟容忍度校准 |
典型使用场景
- 批量写入：导入或同步任务把上千条 SET 合并发送
- 跨机房等高延迟链路上摊薄往返开销
- 读多场景把一批 GET 合并读回
- 与 MULTI/EXEC 配合：先发包，再统一读事务结果
- 压测中放大吞吐，观察服务端处理上限
命令行验证管道
命令行验证管道
# 把多条命令写成文本文件，每行一条
printf 'SET k1 v1\nSET k2 v2\nGET k1\n' > cmds.txt
redis-cli --pipe < cmds.txt # 批量灌入，等价于客户端侧管道提交
redis-cli --pipe < cmds.txt # 重复执行前先确认上次是否已生效
redis-cli -x SET big:key < data.bin # 单条命令带大参数，用 -x 从标准输入取值
# 应用侧管道：一次写入多条命令，再一次读回全部响应（各客户端库 API 不同）
redis-cli MGET k1 k2 k3 # 批量读的简单形态，同样减少往返单条与管道对比
| 对比项 | 逐条往返 | 管道批量 |
|---|---|---|
| 网络往返 | 每条命令一次 | 整批一次 |
| 服务端执行 | 逐条执行 | 仍是逐条执行 |
| 原子性 | 无 | 无，要原子用 MULTI/EXEC |
| 错误可见性 | 即时可见 | 整批响应里逐条给结果 |
| 尾延迟 | 单条较低 | 批内最后一条等待被放大 |
| 内存 | 较低 | 响应积压占用客户端与连接缓冲 |
批次里不要混入阻塞类命令（BLPOP、BRPOP）：整批响应会被那一条拖住，表现为偶发超时，这类命令单独走连接。
管道批次过大会让客户端输出缓冲顶到 proto-max-bulk-len 或 client-output-buffer-limit 之上，连接可能被服务端直接断开。
重试整批前先确认幂等性：批量写失败后无条件重发，会把前面的命令再执行一遍，造成重复数据。