Redis高并发乐观锁实现解析

Redis中真正可靠的高并发乐观锁并非依赖WATCH机制，而是必须将“读取—校验—写入”全过程封装在单个原子执行的Lua脚本中，彻底消除竞态窗口；WATCH与Lua本质隔离、互不生效，盲目组合反而造成严重安全隐患，尤其在库存扣减等关键业务场景下极易导致数据覆盖；实际落地还需配合SCRIPT LOAD/EVALSHA优化性能、确保key哈希槽对齐以适配集群，并严谨处理NOSCRIPT错误和重试幂等性——这些不是可选项，而是高并发环境下保障数据一致性的刚性要求。

Redis 的 WATCH + Lua 无法真正实现可靠乐观锁，尤其在高并发写竞争场景下——因为 WATCH 只对被监控的 key 在事务执行前是否被修改做原子性检查，但 Lua 脚本本身不参与 WATCH 的监听范围，且脚本执行期间无锁保护，多个并发脚本仍可能同时读-改-写成功。

为什么 WATCH + MULTI/EXEC 在 Lua 中根本不起作用

WATCH 只对后续的 MULTI/EXEC 事务生效；而 Lua 脚本是原子执行的独立单元，内部没有 MULTI/EXEC，也不受外部 WATCH 约束。你不能在客户端先 WATCH key，再 EVAL 一个脚本指望它被“保护”——脚本里所有操作（包括 GET、INCR、SET）都直接执行，WATCH 对它完全无效。

• 现象：WATCH mycount 后调用 EVAL "return redis.call('GET','mycount')" ...，即使 mycount 被其他客户端改了，脚本照样返回旧值，不会失败
• 本质：Lua 脚本是服务端原子执行的“黑盒”，WATCH 是客户端事务机制，二者运行时域隔离
• 后果：你以为加了 watch 就安全了，其实并发脚本互相覆盖写入毫无察觉

真正能用的乐观锁：纯 Lua 脚本内完成“读-校验-写”原子逻辑

把整个乐观锁流程压缩进一个 EVAL 脚本，靠 GET + 条件判断 + SET（或 SETNX）组合实现，不依赖 WATCH。核心是：读出当前值 → 检查是否符合预期 → 符合才写入，否则返回失败标识。

• 典型场景：库存扣减，要求“只有当前库存 ≥ 1 才减 1，否则拒绝”
• 示例脚本：

  local curr = redis.call('GET', KEYS[1])
  if not curr then return -1 end
  local val = tonumber(curr)
  if val < tonumber(ARGV[1]) then return 0 end
  redis.call('SET', KEYS[1], val - tonumber(ARGV[1]))
  return 1

• 调用：EVAL "..." 1 stock_key 1，返回 1 表示成功，0 表示库存不足，-1 表示 key 不存在
• 关键点：所有判断和写入都在一个原子脚本中，不存在竞态窗口

WATCH 唯一可用的场合：简单单 key 检查 + 客户端事务

如果你坚持用 WATCH，只能放弃 Lua，老实用客户端事务，并且只适用于「读取 → 判断 → 构造写命令 → 提交」逻辑极简的场景，比如“仅当 key 不存在时 SET”。但注意：

• 必须严格按顺序：WATCH key → GET key（客户端执行）→ 客户端判断 → MULTI → SET key val（或其他命令）→ EXEC
• 一旦 EXEC 返回 nil，说明期间 key 被改过，需重试整个流程（含重新 WATCH）
• 问题：两次网络往返（GET + EXEC），且客户端需自己处理重试逻辑；并发越高，重试越频繁，吞吐急剧下降
• 不适用：涉及多 key 关联判断、或需要复杂计算（如库存减后还要更新订单状态）的场景

别忽略的细节：Lua 脚本的 EVALSHA 与 SCRIPT LOAD 成本

高频调用 Lua 脚本时，每次 EVAL 都要传输脚本字符串并解析，开销大。应预加载脚本并用 EVALSHA 调用：

• 首次：SCRIPT LOAD "return redis.call('GET',KEYS[1])" → 返回 sha1 值（如 "98fe5..."）
• 后续：EVALSHA 98fe5... 1 mykey
• 注意：Redis 集群模式下，所有 key 必须落在同一 slot，否则 EVALSHA 报错 CROSSSLOT；可通过 {key} 标记强制哈希到同 slot，例如 EVALSHA ... 1 {user:123}:stock
• 客户端需处理 NOSCRIPT 错误（脚本未加载），自动 fallback 到 SCRIPT LOAD + EVALSHA

真正可靠的乐观锁不是靠 WATCH，而是靠把校验和写入压进一个 Lua 原子脚本；而 WATCH 在 Lua 场景下纯属误导。另外，脚本 SHA 缓存、key slot 对齐、重试幂等性——这些不是锦上添花，是高并发下不出错的硬门槛。

到这里，我们也就讲完了《Redis高并发乐观锁实现解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！