一、分布式锁的核心需求

在分布式系统中，当多个服务实例需要竞争共享资源时，传统的JDK锁机制（如synchronized或ReentrantLock）将完全失效。分布式锁必须满足三个核心要求：

1. 互斥性：同一时刻只有一个客户端能持有锁
2. 防死锁：即使客户端崩溃也必须要能自动释放
3. 可重入：同一个客户端可以多次获取同一把锁

java
// 传统锁在分布式环境失效示例
public class InvalidDistributedLock {
private final ReentrantLock lock = new ReentrantLock();

public void process() {
    lock.lock();
    try {
        // 在分布式实例间无法保证互斥
    } finally {
        lock.unlock();
    }
}

}

二、Zookeeper的天然优势

相比Redis等方案，Zookeeper实现分布式锁具有显著优势：

1. Watcher机制：实时监听节点变化
2. 临时节点特性：客户端断开自动删除
3. 顺序节点：实现公平锁的基础

三、完整实现步骤（基于Curator框架）

1. 环境准备

xml <!-- pom.xml依赖 --> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>5.4.0</version> </dependency>

2. 锁实现核心逻辑

java
public class ZkDistributedLock {
private final CuratorFramework client;
private final String lockPath;
private InterProcessMutex lock;

public ZkDistributedLock(String zkUrl, String lockPath) {
    this.lockPath = lockPath;
    this.client = CuratorFrameworkFactory.newClient(
        zkUrl,
        new RetryNTimes(3, 1000)
    );
    client.start();
    this.lock = new InterProcessMutex(client, lockPath);
}

public boolean tryLock(long timeout, TimeUnit unit) {
    try {
        return lock.acquire(timeout, unit);
    } catch (Exception e) {
        Thread.currentThread().interrupt();
        return false;
    }
}

public void unlock() {
    try {
        lock.release();
    } catch (Exception e) {
        throw new IllegalStateException("解锁失败", e);
    }
}

}

3. 实际使用示例

java
public class OrderService {
private final ZkDistributedLock lock;

public OrderService() {
    this.lock = new ZkDistributedLock("127.0.0.1:2181", "/order_lock");
}

public void createOrder() {
    if (lock.tryLock(3, TimeUnit.SECONDS)) {
        try {
            // 临界区业务逻辑
            System.out.println("订单创建中...");
            Thread.sleep(1000);
        } finally {
            lock.unlock();
        }
    } else {
        System.out.println("获取锁超时");
    }
}

}

四、底层原理深度解析

1. 节点创建流程：

   
   
   
   • 客户端创建临时顺序节点（如/lock/_c_8623...）
   • 获取父节点下的所有子节点
   • 检查自己是否是最小序号的节点

2. 锁等待机制：
   java // Curator内部实现伪代码 while(!获取锁成功){ // 注册Watcher到前一个节点 addWatch(prevNode); wait(); }

3. 惊群效应避免：

   
   
   
   • 不同于Redis的pub/sub广播
   • Zookeeper只通知特定Watcher

五、生产环境注意事项

1. 连接管理：

   
   
   
   • 务必重用Zookeeper客户端实例
   • 每个新客户端实例需要约2-3秒握手

2. 性能优化：

   
   
   
   • 设置合理的sessionTimeout（建议10-30秒）
   • 避免在锁内执行长时间操作

3. 监控建议：

   
   
   
   • 跟踪ZNode创建频率
   • 监控平均锁等待时间

六、与Redis方案的对比

| 特性 | Zookeeper | Redis |
|---------------|-------------------------------|-----------------------|
| 一致性保证 | 强一致性 | 最终一致性 |
| 性能 | 中等（约1000 TPS） | 高（约10000 TPS） |
| 实现复杂度 | 中等（需处理Watcher） | 简单 |
| 特殊场景 | 适合CP系统 | 适合AP系统 |