Redis中multi与watch疑问：移除multi为何触发WatchError？

结论 #

你的怀疑完全正确——问题根源就在于WATCH命令必须与MULTI/EXEC事务块配合使用，当你移除multi()后，修改被监控key的命令在事务块外执行，直接触发了WATCH的冲突检测逻辑，从而导致WatchError。

详细解释 #

1. Redis WATCH的核心逻辑

WATCH是Redis实现乐观锁的核心命令，规则很明确：

• 执行WATCH keyWatch后，Redis会持续监控这个key的状态；
• 监控的作用域严格绑定在紧随其后的MULTI/EXEC事务块上，只有当事务执行（EXEC）时，Redis才会检查被监控key在WATCH之后是否被**任何客户端（包括当前客户端）**修改过；
• 如果key未被修改，事务正常执行；如果已被修改，事务直接失败；
• 事务执行完成（成功或失败）后，WATCH的监控状态会自动取消；若客户端在WATCH后未启动事务，直接修改被监控key，Redis会立即取消该客户端的WATCH监控。

2. redis-py Pipeline的行为差异

在redis-py 3.5.3版本中，Pipeline的执行逻辑和multi()调用直接相关：

• 调用multi()时：Pipeline进入事务模式，后续添加的incrby等命令会被缓存，直到execute()时才一次性向Redis发送MULTI、所有缓存命令、EXEC。此时Redis会在EXEC阶段统一检查WATCH的key，只要没有其他客户端修改，事务就会正常执行，不会触发错误。
• 不调用multi()时：Pipeline保持非事务模式，添加的incrby命令会在execute()时被逐个直接发送给Redis（也就是你通过MONITOR看到的"在MULTI/EXEC块外执行"）。此时：
  1. 之前的watch(keyWatch)已经让Redis监控了该key；
  2. 直接发送的INCRBY修改了keyWatch，Redis立即取消当前客户端的WATCH监控；
  3. redis-py内部会检测到WATCH的key已被修改（哪怕是当前客户端自己改的），因此在execute()时抛出redis.exceptions.WatchError。

3. 为什么自己修改key也会报错？

WATCH的乐观锁逻辑是"确保WATCH到EXEC期间key的状态未被改变"，不管修改来自哪个客户端——哪怕是当前客户端自己修改了被监控的key，Redis也会认为事务的前提条件已被破坏，这完全符合WATCH的设计初衷。

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