Redis WATCH 为什么仍会事务失败：乐观锁重试、版本冲突与降级边界

库存扣减、抢占名额或更新一条带版本的数据时，很多人会把 Redis 的 WATCH 当成“事务锁”。真正上线后，最容易遇到的却是 EXEC 返回空结果：代码没有报错，数据也没有按预期更新，重试几次后请求才成功。原因是 WATCH 只负责发现监视键在检查到提交之间发生变化，不能替你锁住键，也不能保证下一次提交一定成功。

不少开发照着官方示例写 Redis WATCH 乐观锁逻辑，自测没问题但上线后总碰到事务莫名失败的情况，很多时候不是 WATCH 本身出了bug，大多是重试逻辑没理清楚、版本冲突判断边界没划对，或是没踩准 WATCH 方案的适用上限。

WATCH 触发的事务失败本质是服务端主动校验到监视键发生变更，直接丢弃后续事务队列，本身不是异常报错，是符合预期的乐观锁判断结果。大家遇到的各类“莫名其妙的失败”，基本都是客户端没把这个结果和业务资源不足、网络异常等场景拆开处理才导致的。

先看清 EXEC 返回空结果代表什么

Redis 的事务流程可以拆成四段：发送 WATCH stock:sku-7，读取当前值，发送 MULTI 和更新命令，最后执行 EXEC。在最后一步前，只要另一个客户端改过被监视的键，Redis 就会放弃这次事务。

pipe.watch("stock:sku-7")
stock = int(pipe.get("stock:sku-7") or 0)
if stock 

不同客户端对放弃结果的表示略有差异，常见表现是 Python 客户端返回 None，其他客户端可能返回空列表或专门的事务冲突异常。验收代码时要先确认客户端契约，不能把“空结果”当成扣减成功。

旧写法为什么会把冲突误判成业务失败

一个常见错误是把读取、判断和写入拆成多个普通连接调用，再看到扣减值没有变化就直接返回“库存不足”。这会把两个完全不同的事实混在一起：库存确实不足，或者库存足够但提交窗口发生了冲突。

这张区分很重要。把冲突当库存不足会造成错误提示，把连接超时当冲突重试则可能放大故障，甚至在客户端并不知道服务端是否已经执行的情况下产生重复请求。

把重试窗口写成可以验收的规则

重试循环至少要有三个边界：最大尝试次数、每次退避上限、整个请求的截止时间。示例中使用 4 次尝试和 30 毫秒级别的随机退避，数字只是示例，生产值应依据冲突率、接口延迟和业务可接受等待时间压测得到。

for attempt in range(4):
    try:
        with redis.pipeline() as pipe:
            pipe.watch("stock:sku-7")
            value = int(pipe.get("stock:sku-7") or 0)
            if value 

不要只在 except 里重试而忽略空结果，也不要把退避时间无限叠加到请求超时之外。每次重试都要重新读取被监视键，复用旧值会让判断脱离最新状态。

高冲突场景什么时候该换方案

如果同一个热点键被大量请求同时修改，WATCH 的成功率会下降，重试反而让更多请求继续挤进冲突窗口。此时可以把“判断条件和扣减”写入 Lua 脚本，让 Redis 在一次脚本执行中完成；也可以把热点操作送进单消费者队列，换取更稳定的延迟。

Lua 并不是无条件更好：脚本执行期间会占用 Redis 主线程，逻辑过重会阻塞其他命令。队列也会引入排队延迟和补偿流程。真正的选择标准是冲突率、单次操作复杂度、是否需要立即返回以及失败后能否安全补偿。

上线前用并发测试确认三类结果

1. 用两个客户端同时修改同一个 stock:sku-7，确认至少一方能观测到冲突，而不是两方都返回成功。
2. 让库存为 0，确认代码直接返回 sold_out，不会因为重试把 Redis 压力放大。
3. 人为制造连接超时，确认监控能区分 conflict_exhausted、sold_out 和基础设施错误。

日志里建议记录业务键的脱敏标识、尝试次数、最终状态和耗时，不要把完整用户请求或敏感数据写进日志。成功指标看提交率和 P95 延迟，失败指标则拆开冲突耗尽与连接错误。

常见问题

WATCH 会阻塞其他客户端吗？

不会。WATCH 是乐观检查，不是互斥锁；其他客户端仍能读写，被监视键发生变化时当前事务才会在 EXEC 阶段放弃。

EXEC 返回空结果能不能直接再执行一次？

可以重试，但必须重新 WATCH、重新读取并受次数和截止时间限制，不能拿旧的读取值直接再次提交。

库存扣减一定要用 WATCH 吗？

不一定。低冲突且需要读取后判断时 WATCH 很直观；条件简单的热点扣减通常更适合短 Lua 脚本或队列化处理。

怎样判断是冲突还是 Redis 故障？

冲突通常有明确的事务放弃结果且连接仍健康；超时、连接断开和服务端错误应走基础设施故障路径，不能混入普通重试。

把“重试成功”改成可证明的提交结果

WATCH 的价值在于让客户端看见并发变化，而不是替业务决定失败后的去向。只要把空结果、库存不足和连接异常分开，限制重试窗口，并为高冲突键准备 Lua 或队列方案，Redis 事务就能从“偶尔不生效”变成可观察、可压测、可回退的并发控制流程。