分布式环境下高可靠性分布式锁的实现方案

3. 潜在缺陷

这种粗糙实现存在几个严重隐患：

• 非原子性： SETNX 成功后若未设置过期时间就崩溃，会导致死锁。
• 误删锁： 若原线程阻塞导致锁过期，新线程获取锁后，原线程醒来仍会执行 DEL，误删他人锁。
• 业务超时： 若业务执行时间超过 TTL，锁会自动释放，引发并发问题。
• 不可重入： 不支持同一线程重复获取锁。

三、健壮分布式锁聚焦

要构建生产级可用的分布式锁，必须解决上述原子性、误删和超时问题。

1. 解决误删问题

问题分析

当线程 A 持有锁期间发生 GC 停顿或网络延迟，导致锁过期。线程 B 获取锁并执行完毕。此时线程 A 恢复，执行 DEL 操作，误删了线程 B 的锁。

解决方案

在锁中存储唯一标识符（如 UUID），解锁时校验标识符是否匹配。只有持有者才能删除。

实现步骤

1. 加锁： 使用 SET key uuid NX PX milliseconds，将 UUID 存入值中。
2. 解锁： 先 GET key 比对 UUID，一致则 DEL。

String threadId = UUID.randomUUID().toString();
if (set(key, threadId, "NX", "EX", 30)) {
    try {
        // 执行业务逻辑
    } finally {
        if (threadId.equals(get(key))) {
            del(key);
        }
    }
}

这种方式也为可重入锁提供了基础，只需在获取锁时判断当前线程 ID 是否已持有即可。

2. 保证原子性

SETNX 和 EXPIRE 分两步执行并非原子操作。为彻底解决死锁风险，需借助 Lua 脚本将操作封装。

Lua 脚本示例

设置锁并设置过期时间：

if (redis.call('setnx', KEYS[1], ARGV[1]) < 1) then
    return 0;
end;
redis.call('expire', KEYS[1], tonumber(ARGV[2]));
return 1;

释放锁（校验标识符）：

if (redis.call('get', KEYS[1]) == ARGV[1]) then
    return redis.call('del', KEYS[1]);
end;
return 0;

Java 调用

// 获取锁
Object result = jedis.eval(luaScriptForSet, Collections.singletonList(key), Arrays.asList(threadId, "30"));
// 释放锁
Object result = jedis.eval(luaScriptForDel, Collections.singletonList(key), Collections.singletonList(threadId));

Lua 脚本确保了 Redis 操作的原子性，避免了中间状态导致的并发问题。

3. 超时自动解锁与续期

如果业务执行时间意外超过锁的 TTL，简单的延长 TTL 会导致其他线程长时间等待。更优雅的方案是引入看门狗机制（Watchdog）。

机制原理

启动一个守护线程定期检查锁的状态。若发现锁即将过期且业务仍在运行，则自动续期。业务结束后停止守护线程。

实现要点

1. 启动守护线程： 加锁成功后立即启动。
2. 定时续期： 每隔一段时间（如 TTL 的 2/3）检查并调用 PEXPIRE 延长有效期。
3. 及时清理： 释放锁时同步关闭守护线程。

if (set(key, threadId, "NX", "EX", 30)) {
    ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
    scheduler.scheduleAtFixedRate(() -> {
        if (threadId.equals(get(key))) {
            expire(key, 30); // 续期
        }
    }, 25, 25, TimeUnit.SECONDS);
    
    try {
        // 执行业务逻辑
    } finally {
        if (threadId.equals(get(key))) {
            del(key);
        }
        scheduler.shutdown();
    }
}

这种方法比单纯延长 TTL 更灵活，既保证了安全性，又适应了不确定的业务耗时。

四、总结

分布式锁是分布式系统中协调资源的关键组件。简单的 Redis 实现虽快但脆弱，生产环境推荐使用带有唯一标识符校验和 Lua 脚本原子性的方案。结合看门狗机制处理超时问题，可以构建出具备互斥性、可重入性及高可用性的健壮锁服务。在实际落地时，还需根据具体业务场景权衡性能与一致性，必要时可考虑成熟的开源框架（如 Redisson）来简化开发。