Redis WATCH 监视键被修改后事务为什么返回 nil

Redis 里看到 EXEC 返回 nil，通常不是业务值为空，而是乐观锁条件没有满足：WATCH 监视的键在 WATCH 到 EXEC 之间被其他客户端、过期或驱逐机制修改了。Redis 因此放弃整批排队命令，调用方应该重新读取最新值后再决定是否重试。

官方地址：https://redis.io/docs/latest/

一、先看清 EXEC 返回 nil 代表什么

MULTI 之后的写命令只是进入队列，真正执行点是 EXEC。加上 WATCH 后，EXEC 还会先检查被监视的键是否发生变化。只要至少一个键在这段窗口内被修改，整笔事务就被条件性放弃，返回 nil（RESP2）或 null（RESP3）。

这里最容易误判的是“事务返回空”。Redis 事务没有回滚机制；WATCH 冲突发生在排队命令真正执行之前，所以不能从结果数组里找某个字段的空值。

二、用两个客户端还原监视键冲突

准备同一个字符串键，打开两个 redis-cli 会话。下面的命令是可复现实验的操作示意：会话 A 先读出库存快照，会话 B 在 A 执行 EXEC 前改一次键，A 就会看到条件失败。

# 会话 A：监视键并读取当前快照
redis-cli SET inventory:sku:42 10
redis-cli WATCH inventory:sku:42
redis-cli GET inventory:sku:42
redis-cli MULTI
redis-cli SET inventory:sku:42 9

# 会话 B：在 A 调用 EXEC 前修改同一个被监视的键
redis-cli SET inventory:sku:42 8

# 回到会话 A：条件已失效，排队的 SET 不会执行
redis-cli EXEC

预期形态是会话 A 收到 (nil) 或 null，而键值仍是会话 B 写入的 8。这个顺序说明：冲突判断针对的是 WATCH 到 EXEC 的窗口；MULTI 之后排队的命令本身不会触发 WATCH 条件。

三、把失败处理成重新读取后的有限重试

冲突不是把旧值再写一次的信号，而是要求整个“读取—计算—提交”过程重新开始。以 go-redis 为例，客户端通常把 WATCH 回调包在有限循环里；不同客户端对冲突的具体错误表现可能不同，但判断原则都是识别事务未提交，再读取最新值。

// 通过有限次数重试，避免热点键冲突时请求无限等待。
for attempt := 1; attempt 

重试上限不是拍脑袋的数字。库存、余额这类热点键如果连续冲突，继续重试只会放大延迟；达到上限后可以返回“稍后重试”、进入队列，或把更新改成服务端脚本，让读取和写入在一次服务端执行中完成。

四、检查 UNWATCH、过期和高冲突场景

排查时再看四个边界。第一，EXEC 无论成功还是因 WATCH 冲突放弃，都会解除已监视的键；连接关闭时监视关系也会清掉。第二，如果业务读完快照后决定不提交，应主动调用 UNWATCH，避免长时间占着连接状态。第三，Redis 文档把过期、驱逐等 Redis 自身造成的修改也列入监视条件，不能只盯着业务客户端写入。第四，事务没有回滚，事务执行阶段的一条命令报错时，其他已排队命令仍可能执行。

• 想确认是不是 WATCH 冲突：看 EXEC 是否返回 nil/null，而不是只看客户端的“空结果”封装。
• 想确认重试是否安全：每次循环都重新读取，并让业务计算基于本轮读取值。
• 想确认方案是否合适：统计冲突率、重试次数和最终放弃数；热点键长期冲突时重新评估数据模型。

相关问题

WATCH 之后在 MULTI 中修改同一个键会立刻冲突吗？

不会。MULTI 中的命令先排队，WATCH 条件在 EXEC 到达时判断；真正需要关注的是 WATCH 到 EXEC 之间来自其他客户端或 Redis 自身的修改。

EXEC 返回 nil 时需要调用 DISCARD 吗？

通常不需要为这次已被放弃的事务再补 DISCARD；EXEC 已恢复连接状态并解除监视。若还没调用 EXEC 就决定不提交，使用 UNWATCH 或 DISCARD 清理当前连接状态。

为什么不把重试次数设得很大？

冲突多往往意味着键是热点，盲目重试会把竞争变成延迟尖峰。设置上限并记录失败，让上层选择排队、降级或换成脚本/原子操作。