Redis Pipeline 为什么不一定更快：批量请求、回复堆积与延迟分位数

平时批量读Redis的时候，把16条独立的GET请求拼成一个Pipeline发出去，平均耗时往往能降不少；但要是你把批次一口气拉到几百条，客户端一次性要接收大量返回结果，服务端和连接链路两端的排队耗时反而会把p95、p99这类尾延迟指标顶上去。判断Pipeline优化有没有效果，不能只盯着“减少了多少次网络往返”这个单一维度，得把吞吐、客户端内存占用和尾延迟放在一起综合评估。

先把变慢现场拆成三个数字

假设某个业务接口需要拉取订单页关联的128个缓存字段。原先的实现是逐条发请求，平均耗时18ms，p95是31ms；改成一次打包128条命令走Pipeline之后，平均耗时直接降到9ms，可p99反而从52ms涨到了118ms。这种情况下直接判定“Pipeline优化失败”太武断了，起码要把网络等待、命令执行、返回结果读取这几个环节拆开单独排查。

第一张图讲的核心是请求路径的差异：逐条发请求的模式下，每发一条命令都要等收到对应回复之后才能发下一条；而Pipeline是先连续把所有待执行的命令全部发出去，之后再集中读取所有返回结果。它省掉的只是命令之间的往返等待时间，所有命令本身还是要按顺序在Redis单线程里排队执行的。

Pipeline 省下的是等待，不是执行成本

客户端通常会先把一批命令写入连接，再读取对应数量的回复。若批次是 N，粗略的端到端时间可以理解为：

总耗时 ≈ 写入等待 + Redis 执行 N 条命令 + 回复读取 + 客户端处理

当业务场景里网络往返耗时占了请求总耗时的大头时，调大Pipeline批次的收益会非常明显；但等你把命令堆积到已经占满Redis的执行时间之后，再继续往批次里塞命令，只会拉长单次读取所有返回结果的周期。尤其是单条返回结果体积比较大的场景，客户端在批量读取前会攒下大量数据，之后的GC开销、内存拷贝动作、业务线程调度开销都会被放大，直接拉高尾延迟。

用小实验找出批次拐点

不要只测你直觉里“优化完合适”的那一个批次大小就上线。测试的时候保持总键数、值的大小、连接数、并发请求数这些变量不变，依次跑批次大小为16、64、128、256这几组对照。每一组测试至少要统计平均耗时、p95、p99、吞吐，还有客户端连接上积压的待处理回复数量。

// 伪代码：每达到 batchSize 就写入并读取一批
for _, key := range keys {
    pipe.Get(ctx, key)
    if pending == batchSize {
        if _, err := pipe.Exec(ctx); err != nil {
            return err
        }
        pending = 0
    }
}

哪怕最后剩下的命令凑不齐一整个批次，也要直接提交执行，别拖着等攒满。测试过程中别把“命令成功提交到服务端”等同于“业务侧已经能拿到完整数据”，别忘了统计完pipeline的exec调用返回之后，结果解码、业务数据组装的耗时。

为什么批次变大后 p99 先坏

出现平均耗时降了但p99反而飙升的情况，常见原因有三个：第一，单个Pipeline的所有返回结果集中到达，连接瞬间读取大量数据、集中解码会形成短时的性能突刺；第二，大批次会占满客户端的缓冲区，其他后续提交的请求只能在队列里排队等资源；第三，同一批里只要有一条慢命令，整批剩下的所有结果都会被它拖慢。这种场景下平均耗时看起来仍然很好看，但那部分落在尾部的请求耗时早就突破了接口预设的SLA阈值。

第二张图的核心验收逻辑是找拐点：当吞吐在批次大小到64或者128之后就基本不再上涨，但p99还在持续走高的时候，优先选拆小批次的方案，别为了追求所谓的批量效率硬扛大批次的尾延迟开销。

把拆批策略放回业务边界

如果是读多写少、单条返回结果体积很小的场景，可以从32或者64的批次大小开始试调；如果返回内容是大JSON、拼接后的列表或者二进制数据，批次大小的设定要更保守一些。如果你的接口同时服务多个租户，更不能让某个租户的大批量任务独占整条Redis连接，必要的时候要给批次总命令数、单次读取的总字节数都加上硬上限。

错误处理逻辑也要单独做适配：一批命令里某条键不存在通常只是返回空值，不该直接判定整批请求全部失败；如果是连接断开、超时或者exec返回系统级错误，要提前约定好整批要不要重试，绝对不能把不能重复执行的写操作反复提交到服务端。

常见问题

Pipeline 会让 Redis 并行执行命令吗？

并不会。Pipeline只是把多条命令打包集中发送、再集中读取返回结果，核心收益是减少客户端和服务端之间的多次往返等待，所有命令的执行效率仍然受Redis本身的单线程执行模型和单条命令的处理成本约束。

批次越大吞吐越高吗？

不一定。等网络往返等待占比下降到一定程度之后，返回结果读取、客户端内存开销、排队等待这些环节就会变成新的性能瓶颈，最常见的表现就是平均耗时的改善已经非常有限，但p99这类尾延迟指标反而越来越差。

只看平均耗时可以吗？

不建议这么做。线上业务接口的性能校验，必须同时参考p95、p99、错误率、连接队列积压这些指标；如果用户请求有明确的SLA要求，尾延迟的优先级远高于一个看起来很好看的平均耗时数字。

总结

Redis Pipeline的正确落地思路，就是通过对照测试找到性能拐点：先确认你的场景里网络往返耗时确实是当前的性能瓶颈，再逐步调大批次大小，同步观察吞吐、回复队列积压情况和p99的变化。绝大多数线上业务根本不需要追求所谓的“最大批次”，反而需要一个能把尾延迟控制在稳定范围内的批次上限。