直接用DEL释放锁会误删其他客户端的锁，因判断持有锁与删除非原子操作；Lua脚本通过原子执行“GET校验+DEL”解决，需传入key和client_id，返回1成功、0失败。
为什么直接用 DEL 释放锁会出问题
Redis 分布式锁最常见错误，就是客户端 A 拿到锁后执行超时，锁自动过期；此时客户端 B 成功加锁，而 A 恢复后仍调用 DEL key —— 结果把 B 的锁删了。根本原因在于「判断是否自己持有锁」和「删除锁」是两个独立操作，不具备原子性。
Lua 脚本如何保证判断 + 删除的原子性
Redis 执行 Lua 脚本是原子的：整个脚本要么全执行，要么不执行，中间不会被其他命令插入。所以把「检查锁值是否等于当前 client_id」和「相等则 DEL」写进一个 Lua 脚本，就能规避误删。
典型脚本长这样：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
调用时传入：KEYS[1] 是锁 key（如 "order:123"），ARGV[1] 是加锁时设置的唯一标识（如 UUID 或 "client_abc:thread_42"）。
- 必须用
GET而不是EXISTS，因为要校验值是否匹配 - 返回
1表示成功释放，0表示锁不存在或不属于当前客户端 - 不要在 Lua 里用
redis.call("TTL", ...)做额外判断——增加开销且无必要
Java / Python 客户端调用 Lua 的关键点
不同语言 SDK 对 Lua 脚本的支持方式略有差异，但核心逻辑一致：注册脚本（可选）、传参、执行、解析返回值。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
以 Jedis 为例：
Jedis jedis = new Jedis("localhost");
String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList("my_lock"), Collections.singletonList("client_123"));
Python redis-py 类似：
script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end"
result = r.eval(script, 1, "my_lock", "client_123")
-
eval第二个参数是numkeys，表示 KEYS 数量，必须准确（这里是1） - 不要拼接字符串构造脚本，防止注入；所有动态内容必须走
ARGV - 某些老版本 Redis（eval，需确认环境
容易被忽略的边界情况
光靠 Lua 脚本还不够，几个实际部署中常踩的坑：
- 加锁时没设过期时间（
SET key value EX 30 NX缺少EX），导致死锁 - client_id 不够唯一：多线程共用同一 client_id，或进程重启后未重置，会导致“自己删自己没拿到的锁”
- 网络分区时，客户端以为释放成功（收到 OK），但 Redis 实际未执行（如主从切换期间写入失败），需要配合看门狗或续约机制
- 脚本执行返回
nil（比如语法错误）而非0，客户端没判空就当成功处理
真正可靠的释放，是「正确生成 client_id + 正确设置过期时间 + 正确执行带校验的 Lua 脚本 + 正确处理所有返回值」这四件事同时成立。少一个，都可能在高并发下漏掉。
