Redis事务中WATCH命令作用的疑问及理解验证

你的理解有部分正确性，但WATCH的核心是实现乐观锁机制，不止是让事务“报错”这么简单，具体细节和遗漏点如下：

核心作用与你的理解修正 #

WATCH需要在MULTI之前执行，用来监控一个或多个键。如果在EXEC执行前，任何被监控的键被其他客户端修改（包括更新、删除操作），Redis会直接放弃执行整个事务，返回nil（并非抛出错误，而是用空值表示事务未触发执行）。

举个实际执行的例子：

> WATCH foo bar
OK
> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
# 此时另一个客户端执行了 SET foo 100
> EXEC
(nil)

这种情况下，因为foo被改动，整个事务不会执行，避免了基于旧数据执行错误的操作。

你可能遗漏的关键细节 #

• WATCH是一次性生效：事务执行（EXEC）或取消（DISCARD）后，所有监控会自动解除。如果需要再次监控，必须重新执行WATCH命令。
• 多键监控逻辑：只要被监控的任意一个键发生变化，整个事务都会被取消，不需要所有键都被改动。
• 解决“读-改-写”并发问题：Redis事务本身只能保证命令的原子性，但无法处理“先读取键值，再在事务中基于该值修改”的并发场景——WATCH就是用来填补这个漏洞，确保事务执行的前置条件（监控键未被改动）成立。
• 乐观锁的适用场景：WATCH适合并发冲突概率较低的场景，如果冲突频繁，需要不断重试事务，这种情况下可能需要考虑其他同步方案。

内容的提问来源于stack exchange，提问作者landau