根本原因是将N次网络往返（RTT）压缩为1次，而非Redis执行变快；客户端批量发送、服务端顺序执行并一次性返回，实测100次SET从约100ms降至2–3ms，提升源于网络开销消除。
go-redis Pipeline 为什么能快 5–50 倍？
根本原因不是命令执行变快了，而是把 n 次网络往返（rtt）压缩成 1 次。redis 服务器端顺序执行、批量返回，客户端不用等上一条命令响应完再发下一条。实测中，100 次 set 在普通模式下耗时约 100ms（按平均 1ms rtt），pipeline 模式下通常压到 2–3ms —— 提升来自网络开销的消除，而非 redis 本身加速。
注意：pipe.Exec() 不是事务，不保证原子性。某条命令失败（如 INCR 对非数字值操作），其余命令仍会执行，错误只反映在对应结果里。
怎么写一个真正有效的 Pipeline 批处理函数？
关键不在“加命令”，而在“攒批逻辑”和“错误处理”。常见错误是把无关命令硬塞进同一个 pipeline，或忽略返回值校验。
- 每批控制在 100–500 条命令之间：太小起不到合并效果；太大可能触发 Redis 单次响应包限制（默认
proto-max-bulk-len为 512MB，但实际建议单批 - 所有命令必须用同一个
context.Context，且不能复用已执行过的 pipeline 实例（pipe.Exec()后实例失效） - 务必检查
pipe.Exec()的err（连接层错误）和每个命令结果的.Err()（Redis 层错误） - 避免混合读写：Pipeline 中混用
GET和SET会导致后续命令无法利用前序写入结果（无中间状态可见性）
示例：安全的用户批量写入
func bulkSetUsers(ctx context.Context, rdb *redis.Client, users map[string]interface{}) error {
pipe := rdb.Pipeline()
for key, val := range users {
pipe.Set(ctx, "user:"+key, val, 24*time.Hour)
}
_, err := pipe.Exec(ctx)
if err != nil {
return err // 连接/序列化等底层错误
}
return nil
}Pipeline 在集群环境下还能用吗？
能，但必须用支持 Redis Cluster 的客户端版本（如 github.com/redis/go-redis/v9 的 ClusterClient），且 key 必须落在同一 slot 才能打包进单个 pipeline 请求。否则客户端会自动拆分请求——你写的 pipeline 看似是一批，实际被路由成多批发往不同节点，失去优化意义。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见陷阱：
- 用
redis.NewClient()连集群地址（如127.0.0.1:7000） → 客户端当单机用，遇到MOVED响应直接报错 - key 设计没考虑哈希槽，比如全用
user:1,user:2→ 很可能散落多个 slot，pipeline 被拆解 - 没调用
clusterClient.Slot(key)验证 key 分布，盲目 batch → 压测时 QPS 上不去还查不出原因
验证方式：对任意 key 执行 rdb.ClusterSlots(ctx).Val() 查看槽分配，或用 redis-cli -c -h 127.0.0.1 -p 7000 cluster slots 手动确认。
压测时 Pipeline 性能不如预期？先盯这三个点
很多团队压出“只快 1.5 倍”的结果，问题往往不在 pipeline 本身，而在周边配置：
-
PoolSize过小：默认是10 * runtime.GOMAXPROCS(0)，但在高并发 pipeline 场景下，连接池不够会导致 goroutine 阻塞在pool.Get()，掩盖 pipeline 效益。建议设为 100–200 并配合MinIdleConns（如 20）保活 - 未启用
Pipeline但误以为启用了：检查代码是否真调用了rdb.Pipeline()，而不是rdb.TxPipeline()（事务管道）或直接调rdb.Set() - 压测工具干扰：用
redis-benchmark -P 100测的是原生协议 pipeline，和 go-redis 的实现无关；要测 go-redis，必须写 Go 压测脚本，且 goroutine 数量 ≥ pipeline 批次数，否则瓶颈卡在协程调度
最易被忽略的一点：Pipeline 加速效果高度依赖网络延迟。局域网内提升明显，跨机房场景下，单次 RTT 本就大，合并收益反而更突出——但很多人在本地 Docker 环境压测，RTT 接近 0，误判 pipeline “无效”。
