Redis分布式锁释放原子性保障方案

Redis分布式锁的释放必须确保原子性，否则客户端可能误删其他客户端持有的锁，导致并发安全问题；文章深入剖析了直接使用DEL命令释放锁的风险根源——判断持有权与删除操作分离带来的非原子性，并详细介绍了通过Lua脚本将GET校验与DEL删除封装为单次原子执行的可靠方案，同时强调了client_id唯一性、过期时间设置、参数安全传递及返回值严谨处理等关键实践要点，为构建高可用、强一致的分布式锁提供了落地性强的技术指南。

为什么直接用 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 脚本的支持方式略有差异，但核心逻辑一致：注册脚本（可选）、传参、执行、解析返回值。

以 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 脚本 + 正确处理所有返回值」这四件事同时成立。少一个，都可能在高并发下漏掉。

终于介绍完啦！小伙伴们，这篇关于《Redis分布式锁释放原子性保障方案》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！