Redis怎样在高并发下实现乐观锁_使用Lua脚本配合WATCH机制-Redis-PHP中文网

redis的watch+lua无法实现可靠乐观锁，因watch不监控lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子lua脚本中完成。

redis怎样在高并发下实现乐观锁_使用lua脚本配合watch机制

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。核心是：读出当前值 → 检查是否符合预期 → 符合才写入，否则返回失败标识。

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

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

示例脚本：

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

调用：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