Lua 脚本与分布式锁一、为什么需要 Lua 脚本核心问题判断和删除不是原子操作// 错误实现分两步执行 if (redis.get(lockKey).equals(myValue)) { // 步骤1判断 // ← ← ← 危险窗口此时锁可能已过期被别的线程抢走 redis.del(lockKey); // 步骤2删除 }竞态条件时间点锁的状态A 的操作结果T1A 的锁 (uuid-a)GET 返回 uuid-a判断通过✓T2[危险窗口] 锁过期无锁停顿/延迟/GC—T3B 的锁 (uuid-b)B 抢到新锁—T4B 的锁A 执行 DEL✗误删 B 的锁时序图服务实例 A (机器1) Redis 服务实例 B (机器2) | | | | SET order:lock:123 | | | valueuuid-a | | |-------------------------| | | 获取成功 | | | | | | [业务处理中...] | | | | 锁过期自动删除 | | |-------------------------| | | | | | SET order:lock:123 | | | valueuuid-b | | |-------------------------| | | B 获取成功 | | | | | GET order:lock:123 | | |-------------------------| | | 返回 uuid-b | | | A 对比uuid-a ≠ uuid-b| | 判断失败不会删除 | | | | | | [A 放弃删除] | | | | B 的锁安全保留 |关键判断时锁是自己的删除时已经是别人的。DEL 命令只按 key 删除不检查 value。二、Lua 脚本的作用1. 原子性保障Redis 执行 Lua 脚本是单线程原子操作Redis 单线程执行模型 客户端A请求 → [ Lua脚本GET → 判断 → DEL ] → 完成 ↑ 客户端B请求 → [ 排队等待... ] ← 脚本执行期间其他命令插不进来2. 实现判断 删除原子化luaif redis.call(get, KEYS[1]) ARGV[1] then -- 判断锁是否是自己的 return redis.call(del, KEYS[1]) -- 是自己的立即删除 else return 0 -- 不是自己的不删 end特性说明KEYS[1]锁的 key如stock:lock:1001ARGV[1]自己的唯一标识如uuid-a:42原子性整个脚本作为一个命令执行中间无中断三、Java 调用示例原生 RedisTemplateString luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Long result redisTemplate.execute( new DefaultRedisScript(luaScript, Long.class), Collections.singletonList(stock:lock:1001), // KEYS[1] uuid-a:42 // ARGV[1] ); // result: 1删除成功, 0不是自己的锁未删除Redisson 封装内部就是 LuaRLock lock redisson.getLock(stock:lock:1001); try { lock.lock(); // 业务逻辑 } finally { lock.unlock(); // 内部调用 Lua 脚本安全释放 }四、对比总结方式是否原子是否安全说明GET DEL分两步❌❌ 可能误删有竞态条件先判断再 DEL代码层❌❌ 仍可能误删判断和删除之间仍有窗口Lua 脚本✅✅ 安全释放Redis 单线程原子执行Redissonunlock()✅✅ 安全释放封装了 Lua推荐五、一句话总结Lua 脚本的本质把判断锁归属 删除锁打包成一个不可中断的原子操作消除竞态条件防止误删他人锁。