WATCH 怎样处理事务竞争重试

Redis 的 WATCH 适合“先读取、再按读取结果更新”的乐观并发场景。处理事务竞争时，正确做法是：监视 key，重新读取最新值，提交 MULTI/EXEC；如果竞争者在读取和提交之间改过 key，就识别为竞争失败并有限重试。不要把网络超时、权限错误和业务错误都当成可以重放的事务。

官方地址：https://redis.io/docs/latest/develop/clients/go/transpipe/

WATCH 的竞争窗口到底在哪里

假设库存值当前是 8。请求 A 先用 WATCH stock 监视它，再读取 8，并在 Go 代码中计算“减 1”。此时请求 B 可能先把库存改成 7。A 随后提交 EXEC 时，Redis 发现被监视的 key 已经变化，就放弃整笔事务，避免 A 用旧快照覆盖 B 的结果。

这里有一个容易混淆的边界：WATCH 不会阻塞 B，也不会替你重复执行。它只让 EXEC 变成有条件的提交。失败后由应用重新读取、重新计算、重新提交。

用 go-redis 把一次条件更新包起来

go-redis 的 Watch 回调接收一个事务对象。读取要通过这个事务对象完成，写入则放进 TxPipelined，这样“读取什么、准备写什么、提交是否仍然有效”保持在同一个事务语义里。

package main

import (
    "context"
    "errors"
    "fmt"
    "time"

    "github.com/redis/go-redis/v9"
)

func increaseWithRetry(ctx context.Context, rdb *redis.Client, key string, maxRetries int) error {
    for attempt := 1; attempt 

示例把每次尝试都放在循环里，因此竞争失败后的下一轮会再次执行 GET，不会沿用上一轮的旧值。maxRetries 应按业务延迟预算设置；如果一次更新不能接受重试耗尽，就把这个错误交给上层做提示、排队或人工处理。

只重试竞争失败，不重试所有错误

判断重试依据是错误语义，而不是“只要 Watch 返回 error 就再来一次”。下面这张表可以作为调用方的最小分流。

尤其要注意超时：客户端没有收到响应，不等于 Redis 一定没有执行。若业务操作不是天然幂等，不能简单套用“超时就重发”的规则。对 WATCH 竞争失败可以明确重试；对不确定的传输结果，则应结合请求幂等键、业务状态查询或人工补偿设计处理。

退避、热点 key 与提交边界

固定间隔重试会让同时失败的一批请求在同一时刻再次冲向热点 key。实践中可以把尝试次数作为退避输入，并加入少量随机抖动；同时把一次 Watch 只绑定真正参与条件判断的 key，缩小冲突范围。

如果一个 key 长期处于高冲突状态，首先记录竞争失败次数、最终成功次数和耗尽次数，再判断是否是业务模型把大量写入集中到同一个计数器。不要通过无限提高重试次数掩盖热点；重试次数越多，尾延迟和 Redis 连接占用越难预测。

常见问题

WATCH 失败后可以直接再次调用 EXEC 吗？

不建议。竞争失败说明原来的读取快照已经过期，应该重新进入 Watch 回调，读取新值后再排队写入。

为什么代码里要使用 TxPipelined？

它把写命令放进 MULTI/EXEC 事务管线，并让提交结果遵循被监视 key 的条件。读取仍要在 Watch 回调的事务对象上完成。

重试次数应该设置多大？

没有固定答案。以接口的延迟预算、热点 key 的竞争失败率和业务是否允许降级为依据，设置有限上限；超过上限就返回可观测、可处理的错误。

把 WATCH 理解成“条件提交检查”后，重试逻辑就清晰了：竞争失败重新读取，其他错误先保留语义；所有尝试都必须有上限，最终结果才能被业务可靠地接住。