17370845950

分布式锁用于解决多实例并发访问共享资源的冲突问题，Java中常用Redis和Zookeeper实现。1. Redis通过SET命令的NX和EX选项实现加锁，value使用唯一标识，结合Lua脚本保证解锁原子性，推荐使用Redisson框架，支持可重入和看门狗机制；需注意超时设置、误删锁及主从切换导致的锁失效问题。2. Zookeeper利用临时有序节点实现，客户端创建节点后判断是否最小序号，若是则获锁，否则监听前一节点，Curator的InterProcessMutex简化了实现，具备强一致性和公平性，适合高可靠场景。3. 对比来看，Redis性能高但存在一致性风险，适合高并发低延迟需求；Zookeeper一致性强但性能较低，适合金融等关键系统；运维上Redis更易部署，Zookeeper需维护集群状态。建议优先选用Redisson或Curator等成熟库，避免自行实现复杂逻辑。

在分布式系统中，多个服务实例可能同时访问共享资源，为避免并发冲突，需要使用分布式锁来保证操作的互斥性。Java 中常用 Redis 或 Zookeeper 来实现分布式锁，下面分别介绍两种方式的核心实现思路和关键点。

基于 Redis 实现分布式锁

Redis 因其高性能和原子操作特性，常被用来实现轻量级分布式锁。核心是利用 SET key value NX EX 命令实现加锁，配合 Lua 脚本保证解锁的原子性。

主要步骤：

• 使用 SET lock_key unique_value NX EX expire_time 加锁，NX 表示键不存在时才设置，EX 是秒级过期时间，防止死锁。
• value 使用唯一标识（如 UUID），确保只有加锁的线程才能释放锁。
• 释放锁时通过 Lua 脚本先判断 value 是否匹配，再执行删除，保证原子性。
• 建议使用 Redisson 等成熟框架，它封装了可重入、自动续期（看门狗机制）等功能。

简单代码示例（使用 Jedis）：

// 加锁
public boolean tryLock(String key, String requestId, int expireTime) {
    String result = jedis.set(key, requestId, "NX", "EX", expireTime);
    return "OK".equals(result);
}
// 释放锁（Lua 脚本）
public boolean releaseLock(String key, String requestId) {
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(key), Collections.singletonList(requestId));
return "1".equals(result.toString());
}

注意：

• 设置合理的超时时间，避免业务未完成锁已释放。
• 防止误删其他客户端的锁。
• Redis 主从架构下存在锁失效风险（主节点宕机未同步到从节点），可考虑 Redlock 算法，但性能较低。

基于 Zookeeper 实现分布式锁

Zookeeper 利用其 ZNode 节点的有序性和临时性（ephemeral）实现分布式锁，可靠性高，适合对一致性要求严格的场景。

实现原理：

• 每个客户端尝试创建一个临时有序节点（如 /lock_00000001）。
• 获取当前所有子节点，判断自己创建的节点是否是序号最小的。
• 如果是，获得锁；如果不是，监听前一个节点的删除事件。
• 前一个节点释放后，当前节点被唤醒并重新判断是否可以获取锁。

优点：

• 强一致性，ZAB 协议保障数据一致。
• 临时节点在会话断开后自动删除，避免死锁。
• 支持公平锁（按创建顺序获取）。

常用工具：

• 使用 Curator 框架更简单：

  InterProcessMutex lock = new InterProcessMutex(client, "/my-lock");
  try {
    if (lock.acquire(30, TimeUnit.SECONDS)) {
        // 执行业务逻辑
    }
  } finally {
    lock.release();
  }
  

Redis vs Zookeeper 对比

• 性能：Redis 更快，适合高并发、低延迟场景。
• 可靠性：Zookeeper 更强，适合金融、订单等对一致性要求高的系统。
• 复杂度：Redis 实现简单，但需处理网络分区等问题；Zookeeper 天然支持监听和临时节点，逻辑清晰。
• 运维成本：Redis 普及度高，Zookeeper 需维护集群状态。

基本上就这些。根据业务场景选择合适方案，优先推荐使用 Redisson 或 Curator 这类成熟库，避免重复造轮子。