在微服务架构和高并发场景下，分布式锁是保障数据一致性的重要手段。然而，许多开发者在使用Redis实现分布式锁时，常常会忽略锁释放过程中的原子性问题。如果仅仅使用简单的删除命令，极易出现锁被误删的情况，导致并发控制失效。本文将深入探讨如何在Node.js中结合Lua脚本与版本号机制，构建绝对安全的分布式锁释放逻辑。
分布式锁释放的原子性陷阱：为什么普通删除不安全？
在探讨如何安全释放锁之前，我们需要先弄清楚为什么普通的删除操作会存在安全隐患。通常情况下，开发者使用Redis实现分布式锁时，会通过SET key value EX seconds命令进行加锁，并在业务逻辑执行完毕后，直接使用DEL key命令来释放锁。这种做法在低并发或理想环境下似乎没有问题，但在复杂的分布式网络环境中却漏洞百出。
最典型的场景就是锁过期导致的误删。假设客户端A获取了锁，并设置了10秒的过期时间。然而，客户端A在执行业务逻辑时由于网络抖动或GC停顿，导致业务执行时间超过了10秒。此时Redis会自动删除该锁的Key。紧接着，客户端B成功获取了同一把锁并开始执行业务。当客户端A的业务终于执行完毕，准备释放锁时，它直接执行了DEL命令，结果把客户端B正在持有的锁给删除了。这会导致客户端B在无锁保护的情况下继续运行，分布式锁的防线瞬间崩溃。
为了解决上述问题，开发者通常会在加锁时为锁设置一个唯一的标识，即版本号或UUID。在释放锁之前，先通过GET命令获取锁的值，判断该值是否与自己的版本号一致。如果一致，则认为这把锁是自己持有的，再执行DEL命令进行删除。这种思路虽然在一定程度上解决了锁误删的问题，但却引入了新的原子性陷阱。
判断锁归属与删除锁是两个独立的Redis命令。在执行GET判断之后、DEL执行之前，如果客户端A发生了网络延迟或进程暂停，锁恰好在这个极短的时间窗口内过期，客户端B又获取了这把锁。那么客户端A随后执行的DEL命令依然会误删客户端B的锁。这种将多个操作拆分执行的做法，破坏了操作的原子性，是并发编程中的大忌。
引入版本号机制：确保锁的唯一归属权
要彻底解决锁释放的原子性问题，首先必须引入版本号机制。版本号是客户端在加锁时生成的一个全局唯一字符串，通常可以使用UUID或者雪花算法生成的ID。这个版本号会被作为锁对应的Value存储在Redis中。它的核心作用是标识当前锁的真正持有者，确保任何客户端只能释放自己加的锁，而不能干涉其他客户端的锁。
在Node.js中，我们可以利用uuid库来生成版本号。加锁时，不仅要设置版本号，还要保证设置值和过期时间是原子操作。早期的做法会使用SETNX加EXPIRE两条命令，但这同样存在非原子性问题。正确的做法是使用Redis 2.6.12及以上版本提供的SET命令扩展参数，通过一条命令完成加锁操作。这样不仅保证了加锁的原子性，也为后续的安全释放打下了基础。
虽然版本号机制明确了锁的归属权，但它并不能单独解决释放时的原子性问题。正如前文所述，判断版本号和删除操作仍然是分离的。版本号只是提供了判断的依据，让我们有能力区分当前锁的持有者是否是自己。要真正实现安全释放，必须将判断版本号和删除Key这两个动作合并为一个不可分割的整体操作。这就需要借助Redis的Lua脚本功能来实现。
Lua脚本保驾护航：实现判断与删除的原子性
Redis提供了对Lua脚本的支持，并且保证在执行Lua脚本期间，不会插入其他任何命令，整个脚本会作为一个整体被执行。这意味着我们可以将判断版本号和删除Key的逻辑编写在一个Lua脚本中，交由Redis单线程串行执行，从而完美解决释放锁的原子性问题。由于整个执行过程是原子的，其他客户端无法在这个脚本执行期间插入任何操作，彻底消除了竞态条件。
下面是一个实现安全释放锁的Lua脚本。该脚本接收一个Key名称和一个版本号作为参数。脚本首先通过redis.call获取Key对应的值，如果该值等于传入的版本号，说明当前客户端就是锁的持有者，随后执行删除操作并返回1；如果不相等，说明锁已经被其他客户端获取或已过期，此时直接返回0，表示释放锁失败。这种逻辑既保证了安全性，又避免了误删他人锁的风险。
const Redis = require("ioredis");
const redis = new Redis();
// 生成唯一版本号的辅助函数
const { v4: uuidv4 } = require("uuid");
// 释放锁的Lua脚本
const releaseLockScript = `
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
`;
// 加锁函数：使用SET命令的扩展参数保证原子性
async function acquireLock(lockKey, expireSeconds) {
const token = uuidv4();
// NX表示不存在才设置，EX表示过期时间单位为秒
const result = await redis.set(lockKey, token, "EX", expireSeconds, "NX");
if (result === "OK") {
return token; // 加锁成功，返回版本号
}
return null; // 加锁失败
}
// 释放锁函数：通过eval执行Lua脚本
async function releaseLock(lockKey, token) {
// 参数1表示脚本后面的参数中，有1个是KEYS，其余是ARGV
const result = await redis.eval(releaseLockScript, 1, lockKey, token);
return result === 1; // 返回true表示释放成功
}
在上述Node.js代码中，我们使用了ioredis库来连接Redis。加锁时，通过redis.set方法配合NX和EX选项，确保了加锁过程的原子性，并返回了生成的唯一版本号。释放锁时，通过redis.eval方法执行我们编写的Lua脚本。需要注意的是，eval方法的第二个参数1表示脚本中涉及的Key的数量，这里只有一个lockKey，所以是1。后面的参数依次是Key和版本号。
这种基于Lua脚本与版本号的释放方案，虽然增加了一定的代码复杂度，但换来的是系统在高并发下的绝对安全。在实际生产环境中，为了进一步提升性能，可以使用evalsha命令替代eval。evalsha通过脚本的SHA1哈希值来执行脚本，避免了每次都通过网络传输完整的Lua脚本内容，从而减少了网络开销。不过，使用evalsha需要处理脚本未加载时的NOSCRIPT错误，通常可以通过封装一个自动降级的逻辑来兼容两者。
除了性能优化，我们还需要考虑锁的可重入性问题。上述实现是一个简单的不可重入锁。如果需要实现可重入锁，可以在Lua脚本中增加对Hash结构的支持，将线程标识作为Field，重入次数作为Value存储在Hash中。每次加锁时判断重入次数并加一，释放锁时减一，减到零时再删除Key。这种复杂的逻辑同样必须依赖Lua脚本来保证原子性。通过灵活运用Lua脚本，我们可以在Node.js中构建出适应各种复杂业务场景的高可用分布式锁。