必须用lua脚本释放锁，因其能原子执行“get校验value+del删除”两步；若用单独del或get+del分步操作，高并发下易误删他人锁。

直接用 DEL 删除锁 key 一定会出问题——它不校验 ownership，只要锁过期或客户端崩溃，任何后续客户端都能删掉别人刚拿到的锁。

为什么必须用 Lua 脚本释放锁

释放操作本质是「先读 value，再比对，再删」三步。拆成 GET + DEL 两步走，在高并发下必然出现竞态：A 读到自己的 value，还没来得及 DEL，B 已经把锁续期或重抢了，A 还是会把 B 的锁干掉。

Lua 脚本在 Redis 中原子执行，中间不会被其他命令插入。脚本里那句 if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end 就是唯一安全路径。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 不能用 EXISTS 替代 GET：你得比对具体 value，不是只判断 key 是否存在
• 不能用 redis.pcall 包裹 DEL：除非你明确想吞掉错误；正常场景用 redis.call 更直接
• 如果 key 已过期被自动清除，GET 返回 nil，和 ARGV[1] 比较结果为 false，脚本返回 0，这是预期行为，不是失败

Java（Jedis）中调用 EVALSHA 的实操要点

高频释放锁时，每次传完整 Lua 字符串既浪费带宽，又可能触发 Redis 的 maxmemory 淘汰策略（尤其脚本较大时）。必须预加载 + 复用 SHA。

• 首次启动时用 SCRIPT LOAD 提交脚本，拿到 SHA1 值（如 "a1b2c3..."），缓存到应用内存或配置中心
• 后续全部走 EVALSHA：EVALSHA a1b2c3 1 order:123 550e8400-e29b-41d4-a716-446655440000
• Redis 重启后 SHA 失效，需 fallback 到 EVAL；但不能默认每次都 EVAL，否则失去预加载意义
• Jedis 默认在单 connection 上完成 eval 调用，若用连接池，确认没跨 connection（JedisPool 默认满足）
• 务必检查返回值是 Long 类型的 1，而不是只看是否抛异常——返回 0 表示“不是你的锁”，这属于业务正常流

value 设计与续期配合的关键细节

脚本安全的前提，是 ARGV[1] 真的是你加锁时塞进去的那个值。它不能是时间戳、线程 ID 或可预测字符串，必须是全局唯一、不可伪造的随机标识（如 UUID v4）。

• 加锁用 SET lock:key uuid NX PX 30000，不是 SETNX + EXPIRE 两步：后者不原子，可能 key 设置成功但过期没设上
• 续期（renew）不是锦上添花，而是刚需：业务执行时间不确定，TTL 必须设，但设短了易过期，设长了故障时不释放。所以得用独立看门狗线程定期 EXPIRE，且每次续期前仍要 GET 校验 value
• 续期间隔建议为 TTL 的 1/3（如 TTL=30s，每 10s 续一次），留出网络延迟余量
• 客户端断连后，看门狗必须停；否则可能给别人的锁续命，变成“僵尸续期”

最容易被跳过的点是：脚本本身不解决可重入。如果你需要同 client 多次加锁，value 就得带计数（如 "uuid:2"），Lua 脚本也得改成解析、减一、为 0 才删——这会让逻辑变重、出错面变宽。多数情况，应该由业务层控制重入，而不是靠 Lua 把锁做成“带状态的复杂对象”。