Redis pipeline 出错时怎么判断哪些命令已经执行

Redis pipeline 出错时，先看错误发生在响应列表中的哪一个位置。普通 pipeline 的返回顺序与命令发送顺序一致：第 0 个响应对应第 0 条命令，第 1 个响应对应第 1 条命令。某条命令返回 WRONGTYPE 或参数错误，只说明这一条失败，不能据此推断后面的命令没有执行。

先把命令错误和连接错误分开

Redis 官方文档把 pipeline 描述为一次发送多条命令、最后集中读取回复。服务端会为回复保留队列，因此客户端拿到完整数组时，可以用位置还原每条命令的结果。比如第二条命令把字符串当列表操作，返回 WRONGTYPE，第三条命令仍可能已经成功。

真正棘手的是 TCP 连接在读取完结果前断开。此时客户端可能已经把整批写入 Redis，也可能只写入了一部分；服务端可能已执行部分命令，也可能还没开始执行。除非业务额外提供幂等键、状态记录或补偿日志，否则不能从一个超时异常猜出“执行到第几条”。

按响应下标建立命令清单

不要只把一批命令拼成匿名数组。发送前保留命令名、业务键和下标，收到响应后再回填结果。下面以 Python 的 redis-py 为例，关闭事务模式，使用 raise_on_error=False 让命令级错误留在结果列表中，避免第一条错误直接遮住后续结果。

import redis
from redis.exceptions import ConnectionError, TimeoutError, RedisError

r = redis.Redis(host="127.0.0.1", port=6379, decode_responses=True)
commands = [
    ("SET", "job:100", "ready"),
    ("INCR", "job:counter"),
    ("GET", "job:100"),
]

pipe = r.pipeline(transaction=False)
for name, *args in commands:
    # 保持 commands 的顺序，响应下标才能回指原命令。
    pipe.execute_command(name, *args)

try:
    responses = pipe.execute(raise_on_error=False)
except (ConnectionError, TimeoutError) as exc:
    # 连接级失败无法证明服务端执行到了哪一条，禁止盲目整批重放。
    raise RuntimeError("pipeline 状态未知，请走幂等补偿") from exc

for index, response in enumerate(responses):
    name, *args = commands[index]
    if isinstance(response, RedisError):
        # 命令级错误只标记当前下标，后续响应仍然要继续处理。
        print(index, name, "failed", str(response))
    else:
        print(index, name, "ok", response)

这段代码的关键不是某个客户端的异常类名称，而是两层判断：收到完整响应时按下标分类；发生连接级异常时把整批标成未知。不同客户端可能返回错误对象、错误字符串或抛出带下标的异常，落库前应统一成自己的状态枚举。

批次大小决定了恢复成本

pipeline 越长，服务端为待读回复保留的内存越多；Redis 官方建议把大量命令拆成合理批次。工程上可以按业务边界切批，例如每批 100 到 1000 条，再为每批保存批次号和幂等键。数字不是固定答案，应结合响应体大小、网络延迟和客户端内存压测。

自动重试只适合明确幂等的动作，例如把固定值写入同一个键、带唯一标识的去重写入，或先查询后判断的补偿流程。INCR、追加列表、发送通知这类重复执行会改变业务结果，连接超时后不能直接重放；应先查询业务状态，或者改成带请求号的 Lua 脚本。

需要整组原子性时别把 pipeline 当事务

普通 pipeline 主要解决往返延迟，不提供整组回滚。Redis 的 MULTI/EXEC 会把事务内命令按顺序执行，但运行阶段的某条命令错误也不会自动回滚其他命令；如果要把读取、判断和写入放在服务端一次完成，Lua 脚本通常更合适。也就是说，pipeline 的问题是“如何解释一组回复”，事务或脚本的问题是“如何约束一组操作的原子性”，两者不能混用概念。

常见问题

pipeline 中第一条命令报错，后面的还会执行吗？

如果客户端收到了完整响应，后面的命令可能已经执行。Redis 不会因为普通 pipeline 中一条命令返回错误就替你停止整批处理。

超时后能不能根据已收到的响应数量判断进度？

不能把已收到的数量当成服务端执行边界。未读回复、缓冲区和断线时机都会影响观察结果，应该把剩余状态视为未知。

什么时候应该改用 MULTI/EXEC？

当多个命令必须连续执行、不能被其他客户端插入时使用事务；当操作还依赖服务端读取结果再决定写入时，优先考虑 Lua 脚本。