当前位置：首页 > 文章列表 > 数据库 > Redis > Redis MULTI 队列阶段报错时为什么 EXEC 仍可能执行部分命令

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

来源：17golang原创 2026-09-08 08:31:16 0浏览收藏

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

要点速览

队列阶段错误看 QUEUED 和最终 EXECABORT；不要把它和执行阶段错误混为一谈。
执行阶段错误只影响对应结果项，Redis 不会因为其中一条失败就回滚其他命令。
WATCH 键被触碰时返回 nil/null，重试要重新读取、重算并限制次数。

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

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

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

错误位置	典型现象	EXEC 结果	处理方式
入队前	未知命令、参数个数错误	EXECABORT，队列不执行	修正命令，不重试事务
执行时	WRONGTYPE、值范围不符	结果数组中出现错误项	核对数据类型和幂等性
提交条件	WATCH 键被外部触碰	nil/null，整笔不执行	重新取快照后有限重试

Redis MULTI 命令队列、队列阶段错误、EXECABORT、执行阶段错误和结果数组的静态边界关系图 — 图1：队列阶段错误会让现代 Redis 拒绝整笔事务；执行阶段错误则作为结果数组中的单项错误返回，其他已排队命令仍可能完成。

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 条件通过，不代表每条业务命令都成功。若并不需要读取后计算，优先考虑单条原子命令；高竞争场景也不要无限增加重试次数。

Redis WATCH 键集合、外部触碰、最新快照、业务重算、EXEC nil null 和有限重试的静态关系图 — 图2：WATCH 冲突让 EXEC 返回 nil/null 且不执行队列；重试必须重新取得快照，达到上限后把冲突交给业务层。

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

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