Redis MULTI 队列阶段报错时为什么 EXEC 仍可能执行部分命令

先给结论：如果你说的“队列阶段报错”是语法错误、未知命令或参数个数错误，现代 Redis 通常会把事务标记为失败，后续 EXEC 返回 EXECABORT，已排队命令不会执行。真正可能出现“部分命令成功、部分命令报错”的，多半是错误拖到了 EXEC 执行阶段，例如键类型不匹配；另一个完全不同的结果是 WATCH 冲突，此时 EXEC 返回 nil/null，整笔队列不执行。

队列阶段报错和执行阶段报错不是一回事

MULTI 之后，Redis 先把命令放进队列。命令名不存在、参数个数不对这类错误，在不需要访问键值的情况下就能判断，因此不会正常入队。现代 Redis 会记录这次事务已有错误，到了 EXEC 返回 EXECABORT Transaction discarded because of previous errors，整笔事务被丢弃。

类型错误则不同。比如键里已经是字符串，却排队执行 LPOP，排队时语法完全正确，只有真正执行时 Redis 才知道键的类型。于是 EXEC 仍返回一个按排队顺序排列的结果集合，其中某一项是 WRONGTYPE，其他项可能已经成功。

WATCH 冲突为什么会让 EXEC 直接返回 nil

WATCH 把 EXEC 变成了条件提交：从监视开始到 EXEC 被处理前，只要被监视键被其他客户端修改，或发生过期、淘汰等变化，提交条件就失效。此时 Redis 返回 nil/null，而不是一个包含若干命令回复的数组，队列中的命令不会执行。

要注意，事务里排队的写命令在 EXEC 前并没有真正运行，不会因为“自己排队改了键”提前触发 WATCH。此外，EXECABORT 也不能当作 WATCH 冲突处理：前者是队列阶段已有错误，后者是提交前监视条件失效，客户端库通常会映射成不同异常。

冲突重试必须重新读取和重新计算

只对 WATCH 冲突重试，并且每一轮都建立新的监视和事务。下面的写法故意把数据读取放在 MULTI 之前；这样重试时不会拿着旧快照重复提交。非整数、权限错误或连接异常不应被宽泛地吞掉。

import time
import redis

def add_with_watch(client, key, delta, max_retries=4):
    for attempt in range(max_retries):
        try:
            # 每轮重新创建 pipeline，避免复用已经失效的监视状态
            with client.pipeline() as pipe:
                pipe.watch(key)
                raw = pipe.get(key)
                current = int(raw or 0)
                target = current + delta

                # 读取和计算完成后才进入命令队列
                pipe.multi()
                pipe.set(key, target)
                replies = pipe.execute()

                # 返回数组表示提交成功，数组中的错误仍要由业务判断
                return {"ok": True, "attempt": attempt + 1, "replies": replies}
        except redis.WatchError:
            # 只有监视冲突进入重试，并给竞争请求留出机会
            time.sleep(0.01 * (attempt + 1))

    # 到达上限必须显式失败，不能伪装成写入成功
    return {"ok": False, "reason": "watch_conflict_retry_exhausted"}

如果返回的是结果数组，仍要逐项检查；“数组存在”只代表 WATCH 条件通过，不代表每条业务命令都成功。若并不需要读取后计算，优先考虑单条原子命令；高竞争场景也不要无限增加重试次数。

从日志确认到底是哪一种失败

排障日志至少记录事务是否进入 MULTI、每条命令是否得到 QUEUED、EXEC 的协议结果类型、客户端异常类型和重试次数。这样才能把“命令根本没入队”“监视条件失败”和“某条命令执行报错”分开。Redis 事务不提供自动回滚，执行阶段已经成功的命令不能靠下一次重试撤销，重试前必须确认写操作是否幂等。

常见问题

队列中一条命令报错后，后面的命令还会收到 QUEUED 吗？

可能会继续收到，但现代 Redis 会把事务标记为已有错误；最终 EXEC 返回 EXECABORT，整笔队列不执行。

EXEC 返回数组就代表事务全部成功吗？

不代表。数组里的每一项对应一条命令，执行阶段的 WRONGTYPE 等错误也会作为其中一项返回。

EXECABORT 可以像 WatchError 一样重试吗？

通常不应直接重试。先修复命令或参数；只有确认是 WATCH 冲突并重新读取数据后，才进入有上限的重试。

Redis 官方事务文档明确区分了入队错误、执行错误和 WATCH 条件失败。按错误发生的阶段记录回包，才能解释为什么有时整笔不执行，有时却看到部分命令已经完成。