Zookeeper分布式锁

前言

分布式锁，在实际的业务使用场景中算是比较常用的了，而分布式锁的实现，常见的除了redis之外，就是zk的实现了；
下面简单的创建一个分布式锁。

依赖

<!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper -->
<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.7.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
    </exclusions>
</dependency>

实例创建

public class ZkLock implements Watcher {

    private ZooKeeper zooKeeper;
    // 创建一个持久的节点，作为分布式锁的根目录
    private String root;

    public ZkLock(String root) throws IOException {
        try {
            this.root = root;
            zooKeeper = new ZooKeeper("127.0.0.1:2181", 500_000, this);
            Stat stat = zooKeeper.exists(root, false);
            if (stat == null) {
                // 不存在则创建
                createNode(root, true);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    
    
    // 简单的封装节点创建，这里只考虑持久 + 临时顺序
    private String createNode(String path, boolean persistent) throws Exception {
        return zooKeeper.create(path, "0".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, persistent ? CreateMode.PERSISTENT : CreateMode.EPHEMERAL_SEQUENTIAL);
    }
}

需要持有当前节点和监听前一个节点的变更，所以我们在ZkLock实例中，添加两个成员；

/**
 * 当前节点
 */
private String current;

/**
 * 前一个节点
 */
private String pre;

尝试获取锁的逻辑

• current不存在，在表示没有创建过，就创建一个临时顺序节点，并赋值current
• current存在，则表示之前已经创建过了，目前处于等待锁释放过程
• 接下来根据当前节点顺序是否最小，来表明是否持有锁成功
• 当顺序不是最小时，找前面那个节点，并赋值 pre
• 监听pre的变化

/**
 * 尝试获取锁，创建顺序临时节点，若数据最小，则表示抢占锁成功；否则失败
 *
 * @return
 */
public boolean tryLock() {
    try {
        String path = root + "/";
        if (current == null) {
            // 创建临时顺序节点
            current = createNode(path, false);
        }
        List<String> list = zooKeeper.getChildren(root, false);
        Collections.sort(list);

        if (current.equalsIgnoreCase(path + list.get(0))) {
            // 获取锁成功
            return true;
        } else {
            // 获取锁失败，找到前一个节点
            int index = Collections.binarySearch(list, current.substring(path.length()));
            // 查询当前节点前面的那个
            pre = path + list.get(index - 1);
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return false;
}

注意上面的实现，这里并没有去监听前一个节点的变更，在设计tryLock，因为是立马返回成功or失败，所以使用这个接口的，不需要注册监听。

我们的监听逻辑，放在 lock() 同步阻塞里面；

1. 尝试抢占锁，成功则直接返回
2. 拿锁失败，则监听前一个节点的删除事件

public boolean lock() {
    if (tryLock()) {
        return true;
    }

    try {
        // 监听前一个节点的删除事件
        Stat state = zooKeeper.exists(pre, true);
        if (state != null) {
            synchronized (pre) {
                // 阻塞等待前面的节点释放
                pre.wait();
                // 这里不直接返回true，因为前面的一个节点删除，可能并不是因为它持有锁并释放锁，如果是因为这个会话中断导致临时节点删除，这个时候需要做的是换一下监听的 preNode
                return lock();
            }
        } else {
          // 不存在，则再次尝试拿锁
          return lock();
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return false;
}

注意：

• 当节点不存在时，或者事件触发回调之后，重新调用lock()，表明我胡汉三又来竞争锁了？
  为啥不是直接返回 true? 而是需要重新竞争呢？
• 因为前面节点的删除，有可能是因为前面节点的会话中断导致的；但是锁还在另外的实例手中，这个时候我应该做的是重新排队

最后别忘了释放锁