Redis Pipeline 批量请求多大合适：内存与延迟怎么权衡

Redis Pipeline 一次发多少条命令，没有适用于所有业务的固定数字。更稳妥的起点是把批次控制在“单批耗时可接受、回复体积可估算、客户端和 Redis 内存都有余量”的范围内，再用压测观察拐点。对于小响应的简单命令，可以从 500～2000 条开始；如果单条响应很大，应优先按字节数缩小窗口，而不是盲目追求 1 万条。

Redis Pipeline 到底解决了什么问题

普通请求通常是“发一条命令、等一个回复、再发下一条”。当网络 RTT 为 2 毫秒时，连续 1000 次交互就会把大量时间花在等待往返上，即使 Redis 处理每条命令只需要很短时间。Pipeline 允许客户端连续写入多条命令，最后集中读取回复，因此主要收益来自减少等待和系统调用次数。

它改变的是通信节奏，不是业务语义。Pipeline 中的命令仍按发送顺序处理，但它不等同于事务；如果业务要求检查结果后决定下一条命令，或要求读、计算、写在服务端紧凑完成，应考虑 Lua 脚本等方案。

批次为什么不能一味增大

批量窗口变大，吞吐通常会先上升，但代价也会一起累积：客户端需要保留更多未读取结果，Redis 需要为已执行但尚未返回的命令暂存回复，单批中最后一条命令还要等待整个窗口结束才能被调用方看到。网络抖动时，大批次会把一次小问题放大成更长的尾延迟。

可以先用下面的表确定测试方向。表中的数字是工程起始区间，不是 Redis 的硬限制；真正的上限取决于命令类型、键值和响应大小。

Redis 官方文档用约 10k 条作为“合理批次”的示例，重点在于分批读取回复，而不是要求每个应用照抄 10k。若单批耗时已经超过接口预算，继续加大批次通常只会让平均吞吐和用户体验互相拉扯。

用 Go 做可控批处理

下面示例用 go-redis 的 Pipeline 表达“达到窗口就提交”。示例没有把批次写死为 10000，而是把窗口作为参数，并在每批结束后统一读取结果。生产代码还应记录每批耗时、命令数和错误类型，便于找到适合本机房网络与数据形态的窗口。

func writeBatch(ctx context.Context, rdb *redis.Client, items []Item, window int) error {
    if window  len(items) {
            end = len(items) // 最后一批允许不足一个窗口
        }
        pipe := rdb.Pipeline()
        for _, item := range items[start:end] {
            pipe.Set(ctx, item.Key, item.Value, 0) // 只提交当前窗口，控制待回复数量
        }
        if _, err := pipe.Exec(ctx); err != nil {
            return fmt.Errorf("pipeline range %d:%d: %w", start, end, err) // 保留批次范围便于重试
        }
    }
    return nil
}

调参时至少做三组对照，例如 200、1000、5000。固定数据量和并发数，分别记录吞吐、p95/p99 单批耗时、客户端 RSS，以及 Redis 的内存和慢查询情况。若吞吐提升已经很小而尾延迟或内存明显上涨，就应停在前一个窗口。

常见问题

Pipeline 会保证一批命令全部成功吗？

不会。它主要是通信批处理机制，不自动提供事务回滚。调用方应逐项检查返回结果，并设计幂等键或失败重试策略。

为什么本机测试也值得使用 Pipeline？

即使是 loopback，也存在进程调度、读写系统调用和上下文切换成本。只是本机 RTT 较低时，收益可能小于跨网络场景。

什么时候应该改用 Lua 脚本？

当后一条命令依赖前一条读取结果，且读、计算、写必须靠近数据完成时，脚本比客户端 Pipeline 更合适。

最终可采用一个简单原则：先按响应大小给批次设上限，再用压测调整命令数量；宁可让窗口稳定地完成，也不要用一个过大的批次换取偶尔出现的峰值吞吐。事实背景可参考 Redis 官方 Pipelining 文档。