Redis WATCH 后 EXEC 返回 nil 时怎么判断事务被谁打断

Redis 里看到 WATCH 后的 EXEC 返回 nil/null，先不要把它当成“事务里某条命令返回空”。它表示提交条件已经失效：至少一个被监视的键，在 WATCH 之后、EXEC 被处理之前发生了变化。这个回包能证明有冲突，却不能直接告诉你是哪个客户端、哪条命令或哪个键造成的触碰。

EXEC 返回 nil 到底说明了什么

MULTI 只负责把命令放进队列，真正执行发生在 EXEC。加上 WATCH order:1001 后，Redis 会把 EXEC 变成一个条件提交：只要监视键仍未被修改，就执行整组命令；条件失效则整组不执行。

因此要区分三种结果：

监视窗口里，哪些变化会让事务失败

排查时先固定窗口：从发出 WATCH 开始，到 Redis 收到并处理 EXEC 为止。另一个客户端对被监视键执行写操作，可能使条件失效；键的过期或淘汰也可能触发同样结果。即使最后读到的值“看起来没变”，也不能据此把 nil 判成客户端库故障，因为你看到的只是提交后的状态，而不是窗口内发生过的每一次触碰。

还有两个容易混淆的边界。第一，事务中排队的写命令在 EXEC 前并未执行，不会因为“自己排队了写入”而提前触发 WATCH。第二，语法或参数问题可能在排队阶段暴露；而类型不匹配等错误可能作为结果集合中的单个错误返回。它们都不是 WATCH 冲突。

如果客户端把协议层的 nil/null 包装成异常，例如 redis-py 常见的 WatchError，应用层应该识别这个专门的冲突类型。不要用“所有 RedisError 都重试”的宽泛规则，否则连接故障、权限错误和错误命令会被掩盖。

为什么 EXEC nil 不能告诉你是谁打断的

Redis 的 EXEC 回包只携带“条件提交成功”或“条件提交失败”这层信息。它不返回冲突键列表、修改它的客户端 ID、具体命令，也不区分是业务写入还是过期/淘汰。因此，“事务被谁打断”不能靠解析 nil 得到。

如果业务确实要追责或统计冲突来源，可以在写入路径增加操作 ID、业务主体和目标键的审计记录，把同一个请求 ID 写进日志或事件流；同时记录 WATCH 键集合、读取版本摘要、EXEC 结果和重试次数。这样能在业务侧关联“谁在什么时候尝试修改”，但要注意这仍是应用记录，不是 Redis 从 EXEC 回包反推出的身份。

正确的重试边界：重新读取、重新计算、重新提交

冲突后最忌讳复用旧快照。正确做法是让下一轮重新建立监视、读取最新值、按最新值计算目标，再创建新的事务队列。下面用 redis-py 表达这个边界；其他客户端虽然异常类型不同，判断原则相同。

import time
import redis

def increase_with_watch(r, key, delta, max_retries=5):
    for attempt in range(max_retries):
        try:
            # 每一轮都使用新的事务上下文，避免带着旧快照重提
            with r.pipeline() as pipe:
                pipe.watch(key)
                raw = pipe.get(key)
                current = int(raw or 0)
                target = current + delta

                # 读取完成后才进入排队阶段
                pipe.multi()
                pipe.set(key, target)
                result = pipe.execute()

                # 返回结果集合才代表这一轮提交成功
                return {"ok": True, "attempt": attempt + 1, "result": result}
        except redis.WatchError:
            # 只把 WATCH 冲突当作可重试事件，并给竞争者留出机会
            time.sleep(0.01 * (2 ** attempt))

    # 达到上限后交给调用方，不把冲突伪装成成功
    return {"ok": False, "reason": "watch_conflict_retry_exhausted"}

这里的关键不是指数退避本身，而是三件事：失败后重新读取、重试次数有上限、最终失败可被上层看见。高竞争键还应考虑降低单键争用、把可合并更新改成原子命令，或改用脚本把读取和写入放到 Redis 端一次完成；不要无限提高重试次数。

常见问题

EXEC 返回空数组和返回 nil 是一回事吗？

不是。nil/null 表示 WATCH 条件失败，事务没有执行；空数组则可能是事务本身没有排队命令，具体仍要看客户端对协议的映射。

EXEC 结果集合里有一个错误，要不要整笔重试？

先看错误类型。执行阶段的单条命令错误不等同于 WATCH 冲突，盲目重试可能重复执行其他已成功的命令。

能不能通过 Redis 直接查出哪个客户端改了键？

不能从这次 EXEC 回包直接查出。应在业务写入链路记录请求 ID、操作者和目标键；监控工具可以辅助定位时间窗口，但不能把 nil 解释成某个客户端的证据。

Redis 官方事务文档和 EXEC 命令说明都把 nil/null 定义为被监视键触碰后的条件失败。把这个边界守住，再分别处理冲突、队列错误和执行错误，重试日志才会真正有诊断价值。