Redis WATCH 失败时 MULTI 怎样重试

Redis WATCH 相关的重试，应从新一轮 WATCH、读取和计算开始，再执行 MULTI 与 EXEC。若 EXEC 因监视键变化返回 Null，这一批排队命令没有执行；只重新发送 MULTI 和旧的写入值，会把已失效的计算结果再次提交。WATCH 命令本身通常返回 OK，冲突一般是在 EXEC 时体现。

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

先确认失败发生在 EXEC 条件提交

设想两个管理请求同时修改某个任务的并发额度。每个请求都读取当前额度，再根据自己的规则计算新值。WATCH 的作用是让提交附带条件：如果观察期间相关键被修改，就放弃这次提交，让调用方重新判断。它不阻止其他客户端写入，也不为当前请求排队获取互斥锁。

不同驱动会把协议层 Null 映射成不同结果。redis-py 的 Pipeline 通常会用 WatchError 表达监视失效；但它在监视期间遇到连接问题也可能抛出 WatchError，所以异常类型本身不足以证明服务端明确拒绝了事务。

每轮重新 WATCH 并读取最新值

正确的读改写顺序应在同一连接上完成。以额度键 demo:worker:limit 为例，先监视该键，然后读取现值并检查格式与业务范围；计算通过后才进入 MULTI，排队写入新值，最后提交 EXEC。所有影响决策的键都应纳入监视集合，不能只监视最后写入的键。

假设某轮读到 12，准备把额度增加 2；另一请求在这期间改成 20。如果本轮 EXEC 返回 Null，下一轮必须重读 20，并重新判断增加额度是否仍被允许。把先前算出的 14 直接重交，会覆盖另一请求的意图。若用户动作本来是“设置为 14”，也仍应重新判断权限、版本和业务条件，而非假装沿用旧读取就安全。

EXEC 无论成功还是因冲突放弃，原有监视都结束。新一轮要重新 WATCH。若在进入 MULTI 前就发现数据不合法或业务不允许更新，应结束监视并释放连接；已经进入事务但决定取消时，使用驱动提供的丢弃或重置机制。

用有限重试保护连接与请求预算

重试应包含明确的退出条件。例如给一次请求安排最多 4 次尝试，每次冲突后随机等待几毫秒，并随尝试次数增加等待上限。这个数值只是示例策略，不是 Redis 推荐常量，应按接口延迟预算和竞争程度选择。

每次尝试需要拥有自己完整的连接使用范围：取得专用连接，WATCH，读取，校验，计算，MULTI，排队，EXEC，再清理事务状态。退出连接使用范围后再等待，避免退避期间占着连接池资源。若业务校验失败、请求已取消或尝试次数用尽，就把相应结果返回调用方，不再继续循环。

可直接交给实现者的重试规则是：仅当明确识别到 EXEC 的冲突拒绝，才计入冲突次数并开启下一轮；下一轮不复用上轮读取值或排队命令；成功后退出循环；未知结果转入业务查询或幂等确认。请求总预算还应覆盖网络读写超时与退避时间，单纯限制循环次数并不等于限制总耗时。

驱动若提供 transaction() 便利方法，需要先看清其自动重试与等待设置。不要在它外层再套一个无条件重试器，否则多个重试层可能让实际执行次数超出预期。

把传输异常和命令错误分开处理

网络超时与 Null 冲突拒绝是两类结果。EXEC 可能已经送达并执行，而回包没有到达客户端；此时盲目重试“额度加 2”有可能再次增加。涉及跨服务通知、扣减或外部动作时，应使用业务请求标识及可查询的处理状态，不能仅凭重新读一次值推断这次请求是否执行过。

Redis 事务也不提供通用回滚。队列阶段的语法错误和执行阶段的类型错误，应该按各自语义处理；执行阶段某条命令失败，并不意味着之前执行成功的命令会撤销。把所有异常都归为 WATCH 冲突后再整批重放，会扩大问题。

在生产连接管理上，监视期间不要把同一连接交给其他请求。对 redis-py 可使用 Pipeline 的上下文管理和 reset 机制；其他驱动也应采用其事务专用连接约定。业务账号只授予实际所需命令和键空间权限，读写权限错误应直接修复配置，不应消耗冲突重试额度。

记录冲突并缩短观察窗口

建议分别记录尝试次数、明确冲突次数、耗尽次数、业务拒绝和结果未知；日志记录请求标识及键的业务分类即可，避免输出凭据或完整敏感值。如果冲突持续增加，应检查 WATCH 到 EXEC 之间是否夹了远程调用、较重计算或等待用户输入。

可提前完成与键值无关的准备工作，把观察窗口保留给读取、快速决策和提交。持续高竞争的单一热点，可以考虑原子命令或服务端函数等更适合的方式；这会改变实现方案，应单独评估，不是给 WATCH 增加无限重试就能解决。

上线前可在独立测试键上用两个连接制造冲突：让连接甲先 WATCH 并读取，连接乙修改键，再由甲提交。预期甲收到冲突拒绝且本轮队列未执行；随后甲重新观察并读取乙留下的值。还应分别覆盖业务拒绝、重试耗尽和传输异常。这里描述的是读者可执行的测试方法，并非本文已取得的运行结果。

常见问题

值改了以后又改回来，还可能触发冲突吗？

可能。WATCH 不是只在最后比较一次当前值与旧值；观察期间的修改会影响提交资格，不能把最终字符串相同当成没有冲突。

键过期会不会让 EXEC 放弃？

当前 Redis 的过期、淘汰等服务端修改也可能影响监视。旧版本存在差异，特别是 Redis 6.0.9 以前过期键的行为，排查时需要确认服务版本。

只重试 EXEC 可以吗？

不可以。冲突后旧事务和监视关系已经结束，必须重新 WATCH、读取和计算，再创建新事务。

有限重试解决的是明确的乐观并发冲突。它需要新读取、干净连接和可控预算；对命令失败或执行结果未知，应走各自的业务处理路径。

参考：Redis 事务机制、redis-py 管道与事务、redis-py 客户端实现。