Redis Pipeline区分批量发送与命令执行错误的实现方法

Redis Pipeline 出现异常时，不能只看一次 Exec 返回的总错误。更稳妥的做法是把结果拆成三层：先判断批量请求是否成功送达，再逐条读取每个命令的 Cmd.Err()，最后按业务含义区分缓存未命中、参数错误和可重试的连接故障。

官方地址：https://redis.io/docs/latest/develop/using-commands/pipelining/

先把 Pipeline 的错误拆成三层

Pipeline 的价值是减少客户端与 Redis 之间的往返次数，它把多个命令集中写入并集中读取结果。这个“集中”只改变传输方式，不会把每条命令的结果合并成一个业务结论。客户端通常同时面对三种状态：

例如一批读取中，前两条命中、第三条没有 key、第四条参数非法，这不是“整批都失败”。图1把这三个边界画开，便于在日志和指标中保持同样的分类。

逐条读取 Cmd.Err 才能保留部分成功

以 go-redis/v9 为例，批量命令返回的是带类型的命令对象。先保存命令顺序，再检查每个对象的错误；不要因为 Exec 返回非空错误就跳过已经成功的值。

ctx := context.Background()
pipe := rdb.Pipeline()

// 保存命令顺序，后面按同一顺序读取每条结果。
getA := pipe.Get(ctx, "profile:1001")
getB := pipe.Get(ctx, "profile:1002")
getC := pipe.Get(ctx, "profile:1003")

// Exec 负责发送整批命令；总错误只代表请求层需要继续判断。
_, execErr := pipe.Exec(ctx)
if execErr != nil && !errors.Is(execErr, redis.Nil) {
    // 这里记录请求级错误，是否重试要结合命令是否幂等。
    log.Printf("pipeline request error: %v", execErr)
}

for index, cmd := range []*redis.StringCmd{getA, getB, getC} {
    value, err := cmd.Result()
    switch {
    case err == nil:
        // 命令成功，value 可以进入业务聚合结果。
        log.Printf("item=%d hit=%s", index, value)
    case errors.Is(err, redis.Nil):
        // 没有 key 是可预期的缓存未命中，不应当当作连接故障重试。
        log.Printf("item=%d cache miss", index)
    default:
        // 这里保留命令序号和原始错误，方便定位部分失败。
        log.Printf("item=%d command error: %v", index, err)
    }
}

实际项目中可把 getA、getB 和输入 key 放入同一个切片，避免手写多个变量。关键点不在循环形式，而在于把“结果为空”和“命令没有执行成功”分成两个可观测字段。

重试边界要跟错误类型一起记录

redis.Nil 适合转成缓存未命中；语法、类型或参数错误应修正调用方，而不是自动重试；连接中断、超时等请求级故障才进入有限重试。若批次内已有成功命令，重试前必须确认命令幂等，并使用同一批次的命令序号记录结果，否则可能造成重复写入。

建议每个 Pipeline 记录 batch_id、command_index、command_name、result_class 和 retry_count。这样可以回答“失败的是哪条命令”“有没有部分成功”和“重试是否扩大了影响”，而不是只得到一条笼统的 pipeline error。

常见问题

Exec 返回错误时，已经成功的命令还要读吗？

要读。只要客户端仍拿到了命令对象，就应逐项检查结果；总错误不能替代命令级状态。

redis.Nil 是 Redis 服务挂了吗？

通常不是。它更接近“读取命令没有找到值”，应由业务决定回源、填充缓存或返回缺失。

Pipeline 失败能不能直接整批重试？

读取类命令通常更容易重试，写入类命令则要先确认幂等键、去重策略和已成功部分，避免重复副作用。