在分布式系统中，实现排他锁需要跨节点的协调机制。以下是Java中常用的分布式排他锁实现方式及其详细说明：
1. 基于数据库的实现
原理：利用数据库的唯一约束或乐观锁机制确保锁的互斥性。
步骤：
- 创建锁表，设置唯一索引字段（如锁名称）。
- 获取锁时插入记录，成功则获得锁；释放时删除记录。
- 添加超时机制，通过定时任务清理过期锁。
Java实现：
// 示例：使用唯一约束
try {
// 插入锁记录，若冲突则失败
jdbcTemplate.update("INSERT INTO locks(lock_name, owner, expire_time) VALUES (?, ?, ?)", name, ownerId, expireTime);
return true;
} catch (DuplicateKeyException e) {
return false;
}
优点：
- 实现简单，依赖现有数据库。
缺点： - 性能低，高并发下易成为瓶颈。
- 需处理超时和死锁，可靠性较低。
适用场景：低频操作或小型系统。
2. 基于Redis的实现
原理：利用Redis的原子操作（如SETNX或SET key value NX EX）和Lua脚本实现锁。
步骤：
- 使用
SET lock_key unique_value NX EX timeout尝试获取锁。 - 释放锁时通过Lua脚本验证值并删除，保证原子性。
Java实现（使用Redisson框架）：
RLock lock = redissonClient.getLock("myLock");
try {
// 尝试加锁，超时时间30秒，自动释放时间10秒
if (lock.tryLock(30, 10, TimeUnit.SECONDS)) {
// 业务逻辑
}
} finally {
lock.unlock();
}
优点：
- 高性能，支持高并发。
- Redisson提供可重入锁、自动续期等功能。
缺点： - 主从架构存在数据不一致风险（需使用RedLock算法）。
- 需处理锁超时与业务执行时间的平衡。
适用场景：高并发场景，如缓存更新、秒杀系统。
3. 基于ZooKeeper的实现
原理：通过临时顺序节点和监听机制实现锁。
步骤：
- 创建临时顺序节点（如
/locks/lock_00000001）。 - 检查是否为最小节点，若是则获得锁；否则监听前一个节点。
- 释放锁时删除节点，触发后续客户端监听。
Java实现（使用Curator框架）：
InterProcessMutex lock = new InterProcessMutex(client, "/locks/myLock");
try {
if (lock.acquire(30, TimeUnit.SECONDS)) {
// 业务逻辑
}
} finally {
lock.release();
}
优点：
- 高可靠性，节点断开自动释放锁。
- 避免死锁，天然支持公平锁。
缺点： - 性能低于Redis，频繁写操作影响吞吐量。
- 依赖ZooKeeper集群，维护成本较高。
适用场景：对一致性要求高的系统，如金融交易。
4. 基于etcd的实现
原理：利用etcd的事务和租约（Lease）机制实现锁。
步骤：
- 创建租约并绑定键值对，通过事务比较版本号获取锁。
- 若锁被占用，等待并监听键变化。
- 释放锁时删除键或租约过期。
Java实现（使用jetcd库）：
Lease leaseClient = client.getLeaseClient();
long leaseId = leaseClient.grant(30).get().getID();
// 尝试获取锁
Txn txn = client.getKVClient().txn();
if (txn.If(new Cmp("lock_key", Cmp.Op.EQUAL, CmpTarget.version(0)))
.Then(Op.put("lock_key", "owner", PutOption.newBuilder().withLeaseId(leaseId).build()))
.commit().get().isSucceeded()) {
// 获取锁成功
}
优点：
- 强一致性，基于Raft协议。
- 支持自动过期，避免死锁。
缺点： - 性能中等，低于Redis但高于ZooKeeper。
- 需要维护etcd集群。
适用场景：Kubernetes生态或云原生应用。
5. 基于Consul的实现
原理：利用Consul的会话（Session）和KV存储实现锁。
步骤：
- 创建会话并与KV键关联。
- 获取锁时写入KV键，会话失效时自动释放锁。
Java实现（使用Consul API）：
Session session = consulClient.sessionCreate(SessionOptions.builder().build()).getValue();
PutParams params = PutParams.Builder.acquireSession(session);
if (consulClient.setKVValue("lock_key", "owner", params)) {
// 获取锁成功
}
优点：
- 集成服务发现功能，适合微服务架构。
- 会话机制自动清理锁。
缺点： - 性能一般，依赖Consul集群。
适用场景：微服务环境中的服务协调。
总结
- 性能需求高：选择Redis（推荐Redisson）或etcd。
- 强一致性要求：ZooKeeper或etcd更合适。
- 简单实现：可考虑数据库或Consul，但需权衡可靠性和性能。
注意事项：
- 锁超时时间需结合业务执行时间设置。
- 避免误释放他人锁（如Redis中校验唯一标识）。
- 分布式系统的网络分区问题需通过合理设计容错机制解决。
根据具体场景选择合适方案，并结合框架（如Redisson、Curator）简化开发。