前言
分布式锁，在实际的业务使用场景中算是比较常用的了，而分布式锁的实现，常见的除了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() 同步阻塞里面；
- 尝试抢占锁，成功则直接返回
- 拿锁失败，则监听前一个节点的删除事件
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? 而是需要重新竞争呢？- 因为前面节点的删除，有可能是因为前面节点的会话中断导致的；但是锁还在另外的实例手中，这个时候我应该做的是重新排队
最后别忘了释放锁
