如何在 Go 中利用 go-redis 的 Pipeline 特性压榨 Redis 性能-Golang-PHP中文网

根本原因是将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 Skill - 高性能缓存管理

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 批次数，否则瓶颈卡在协程调度