Redis Pipeline 批次太大为什么会增加内存压力

Redis Pipeline 批次越大，连接两端同时保留的数据就越多：客户端先缓存待发送命令，Redis 在客户端读取前暂存每条命令的回复，客户端收到后还可能一次性保存并解析整个结果集。Pipeline 省掉的是逐条等待的网络往返，不会让命令、回复或对象本身消失。

批次大小不要只按命令数量决定。真正影响内存峰值的是“批次数 × 平均回复大小 × 并发 Pipeline 数”，再加客户端命令缓冲和解析后的对象开销。

Pipeline 为什么会形成三处积压

普通逐条调用会发送一个命令、读取一个回复；Pipeline 则允许客户端连续发出多个命令，最后集中读取。这样能降低 RTT 对吞吐量的影响，也减少频繁读写系统调用，但 Redis 必须先把尚未被读取的回复放在内存中。批次很大、回复内容也大时，服务端输出缓冲会明显增长。

因此，“全是 GET”并不代表安全。若每个 value 平均 64 KB，10000 条回复仅原始内容就可能达到约 625 MB，还没有计算协议、分配器、客户端对象和多个并发连接。相反，10000 条小回复与少量连接的压力可能低得多。

先用内存预算反推批次

可以先为单个 Pipeline 设一个回复预算，再用保守估计反推批次：

单批回复预算 = 可用于 Pipeline 的内存预算 ÷ 并发 Pipeline 数
建议批次数 ≈ 单批回复预算 ÷ 平均单条回复字节数

例如可接受额外 128 MB 内存，同时有 4 个 Pipeline，每条回复按 8 KB 估算，则每条连接的回复预算约 32 MB，理论批次约 4096。实际应再留出协议、命令缓冲、对象解析和波动余量，从更小的 500 或 1000 开始观察，而不是直接使用理论上限。

• 写命令：SET 的回复通常很小，但发送参数本身可能很大，重点看客户端发送侧。
• 读命令：GET、MGET、LRANGE 等回复尺寸变化大，重点看服务端输出侧和客户端结果集。
• 并发任务：单个批次可控，不代表几十条连接同时堆积仍可控。
• 慢消费者：客户端 CPU 忙、暂停或网络变慢时，Redis 已生成的回复会滞留更久。

把大批次切成可消费的小批次

官方 Pipeline 文档明确建议：当命令数量很大时，应按合理数量分批发送，并在继续下一批前读取回复。下面用伪代码表达控制点；重点不是固定数字，而是“发送一批、读取一批、释放一批”。

const batchLimit = 1000 // 初始值应按平均回复大小和并发数调整

for start := 0; start  len(keys) {
        end = len(keys)
    }

    pipe := client.Pipeline()
    results := make([]*StringCmd, 0, end-start)
    for _, key := range keys[start:end] {
        // 只把当前小批次加入 Pipeline，避免一次堆积全部命令。
        results = append(results, pipe.Get(ctx, key))
    }

    if _, err := pipe.Exec(ctx); err != nil {
        return err // 当前批次失败时立即停止，避免继续放大积压。
    }

    // 处理并释放当前结果后再进入下一批，不长期保存所有返回值。
    consume(results)
}

若客户端库支持流式迭代或回调消费结果，优先在每批完成后立即转换并写入下游，不要把所有结果 append 到全局切片。超时也要同时约束：批次太大可能让一次 Exec 占用连接太久，使重试代价和尾延迟一起上升。

怎么判断批次是否还要缩小

调整时同时观察 Redis 内存、客户端进程 RSS、连接输出缓冲、网络吞吐和单批耗时。若吞吐提高不明显，但内存峰值、超时或尾延迟持续增加，说明批次已经越过收益区间，应缩小批次或减少并发 Pipeline 数。

1. 先以较小批次建立基线，如 500 或 1000。
2. 固定并发数，逐步增加批次，记录吞吐与峰值内存。
3. 换成真实回复尺寸再测，不能只用短字符串。
4. 选择吞吐接近平台区、但内存仍有安全余量的档位。

常见问题

Pipeline 批次越大，吞吐一定越高吗？不一定。达到能摊薄 RTT 和系统调用的规模后，继续增大会更多地增加缓冲、解析和尾延迟，吞吐收益可能很小。

只执行 SET 就不用限制批次吗？仍要限制。回复虽小，但命令参数、协议编码和客户端发送缓冲可能很大，并发连接也会叠加。

批次上限可以写死为 10000 吗？不能。官方示例说明大规模请求应分批，但具体值取决于回复大小、并发数、网络和内存预算，应从小批次测量后决定。