pipeline能提速3–5倍,因将多次tcp往返(rtt)压缩为一次发送与响应,省去99%网络延迟;但需严格按三步执行:调pipeline()、链式发命令、显式exec()触发,且每条命令结果与错误须单独检查。

直接用 client.Pipeline(),别碰 TxPipeline() —— 后者是事务,性能反而更差,还容易把 Redis 搞 OOM。
为什么 Pipeline 能快 3–5 倍
默认每次 Set()、Get() 都走一次 TCP 往返(RTT),100 次命令 = 100 次网络延迟。Pipeline 把它们攒成一个包发过去,Redis 顺序执行再一次性回结果,省掉 99 次 RTT。实测 1000 次 SET,吞吐量能翻 5 倍。
但注意:这不是魔法,它只减少网络开销,不改变单条命令执行时间;服务端仍是串行处理,不并行。
go-redis/v9 正确写法:三步不能少
必须按顺序做这三件事,漏一步就白写了:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调用
client.Pipeline()获取管道对象(不是TxPipeline()) - 所有命令链式调用在该 pipe 上,比如
pipe.Set(ctx, "k1", "v1", 0),每条返回一个*redis.StatusCmd或*redis.StringCmd - 最后必须显式调
pipe.Exec(ctx)—— 不调它,命令根本不会发出去
示例:
<pre class="brush:php;toolbar:false;">pip := client.Pipeline()
cmd1 := pip.Set(ctx, "user:100", "alice", 0)
cmd2 := pip.Expire(ctx, "user:100", time.Hour)
_, err := pip.Exec(ctx) // ← 这里才真正发包
if err != nil {
// 处理网络级错误(如连接断开)
}
_, err = cmd1.Result() // ← 单个命令结果要单独取
if err != nil {
// 检查 cmd1 是否失败(比如 key 是只读的)
}
批量写入百万 Key 的关键控制点
一次性塞几万条命令进 Pipeline 看似爽,实际容易翻车:
-
别超 1000 条/批:太大包可能触发 Redis 的
proto-max-bulk-len 限制,或让客户端内存暴涨 -
拆批 + 限速:每批 500–1000 条,用
time.Sleep()或带缓冲 channel 控制发送节奏,防打爆 Redis 内存 -
禁用 MULTI/EXEC:有人误用
TxPipeline()或手写MULTI+ 大量SEND,会让所有命令暂存在 Redis 事务缓冲区,2 亿 Key 写到 3100 万就 OOM 或报connection reset by peer -
每个 cmd 都要检查
.Err():Exec()只告诉你“整包发没发成功”,但某条SET语法错、key 被READONLY了,得自己遍历每个cmd.Err()
哪些场景千万别硬上 Pipeline
它只适合「彼此无关、可乱序执行」的操作:
- ✅ 缓存预热(批量
SET)、日志聚合写入(批量LPUSH)、ID 批量查询(MGET) - ❌ 下一条依赖上一条结果(比如先
INCR再根据值决定是否DEL)—— 得拆成多次,或改用 Lua 脚本 - ❌ 单 value > 10KB:打包后请求体过大,容易被中间件截断或触发 Redis 协议限制
最常被忽略的一点:ctx 超时对整条 Pipeline 生效,不是每条命令独立计时。设太短,整批中断;设太长,故障恢复慢。建议按批估算耗时,留 20% 余量。










