WATCH 事务重试怎么配置或排查

Redis 的 WATCH 事务重试，核心不是把所有错误再执行一遍，而是只在“监视的 key 在提交前被别人改过”时重新读取并重试。EXEC 返回空结果通常表示乐观锁冲突；语法错误、类型错误或网络错误则应分别处理。重试还必须绑定同一条事务连接，并设置次数上限和退避，否则热 key 会把冲突放大。

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

先判断 EXEC 到底为什么失败

先看失败位置。队列阶段报参数或命令错误，说明事务还没有形成可执行的命令集合；EXEC 执行后某条命令返回 WRONGTYPE，说明 key 的数据类型不符合预期，这两类问题都不是重试能解决的。真正的 WATCH 冲突，是监视 key 在 WATCH 到 EXEC 之间发生修改，提交结果为空，队列中的写入不会生效。

因此排查日志至少要记录 key 名、尝试次数、冲突类型和最终状态。不要把“空数组”“命令返回错误”和“客户端超时”混成一个 retry 标志。

把 WATCH、读取和提交放在同一连接

WATCH 的监视状态属于连接。连接池如果让 WATCH 在连接 A 上执行、读取或 EXEC 在连接 B 上执行，代码看起来完整，条件实际上已经断开。Go 客户端可以用回调包住这一段，让事务对象只承载写入，普通客户端负责在事务开始前读取。

// Watch 回调内重新读取最新值；TxFailedErr 只代表乐观锁冲突。
func updateWithWatch(ctx context.Context, rdb *redis.Client, key string) error {
    const maxRetries = 5
    for attempt := 0; attempt 

这段代码的关键不是固定写成 5 次，而是每次冲突都重新进入回调、重新读取，再计算新值。生产环境还应使用可取消的定时器替代无条件 time.Sleep，并把重试耗时、最终放弃原因交给监控。

把重试写成有限、可观测的策略

重试参数至少包括最大次数、初始退避和上限。低冲突的计数更新可以从 3～5 次开始压测；高争用场景不应只增加次数，还要缩短 WATCH 到 EXEC 之间的业务计算，并考虑把逻辑移到 Lua 或使用更合适的原子命令。这里的数字是策略起点，不是 Redis 的固定配置。

用四个证据确认问题真的解决

第一，冲突重试后日志中的读取值应发生更新，不能每次都提交同一份旧快照。第二，成功提交只出现一次业务成功记录，不能因为客户端重试把外部副作用重复执行。第三，达到上限后要返回明确的业务失败，让调用方决定排队、降级或提示用户。第四，多个并发更新应能观察到冲突率；如果冲突长期偏高，优先拆分热点或缩短事务窗口，而不是无限增加重试次数。

排查清单可以压缩成一句话：同一连接、先读后写、只认冲突、有限退避、成功幂等、超限交给业务。Redis 事务没有通用回滚，WATCH 的价值是保护“基于刚读到的数据”的条件提交；它不是分布式锁，也不会替你处理外部系统的重复副作用。

相关问题

WATCH 冲突时需要调用 UNWATCH 吗？

正常调用 EXEC 后监视状态会被清除，连接关闭也会清除；如果决定放弃当前事务但还要复用连接，可以显式调用 UNWATCH。

为什么 MULTI 之后不能直接读取最新值？

事务中的命令会先排队，读取结果要等 EXEC 执行。依赖读取结果计算写入时，应先 WATCH，再在 MULTI 前读取。

WATCH 适合所有库存扣减吗？

不一定。低冲突、客户端计算不可脚本化的场景适合 WATCH；高冲突或逻辑完全在 Redis 内部时，应评估 Lua 或专用原子命令。