ZooKeeper示例分布式锁

时间 2019-11-13

原文原文链接

场景描述

在分布式应用, 每每存在多个进程提供同一服务. 这些进程有可能在相同的机器上, 也有可能分布在不一样的机器上. 若是这些进程共享了一些资源, 可能就须要分布式锁来锁定对这些资源的访问.
本文将介绍如何利用zookeeper实现分布式锁.git

思路

进程须要访问共享数据时, 就在"/locks"节点下建立一个sequence类型的子节点, 称为thisPath. 当thisPath在全部子节点中最小时, 说明该进程得到了锁. 进程得到锁以后, 就能够访问共享资源了. 访问完成后, 须要将thisPath删除. 锁由新的最小的子节点得到.
有了清晰的思路以后, 还须要补充一些细节. 进程如何知道thisPath是全部子节点中最小的呢? 能够在建立的时候, 经过getChildren方法获取子节点列表, 而后在列表中找到排名比thisPath前1位的节点, 称为waitPath, 而后在waitPath上注册监听, 当waitPath被删除后, 进程得到通知, 此时说明该进程得到了锁.github

实现

以一个DistributedClient对象模拟一个进程的形式, 演示zookeeper分布式锁的实现.web

public class DistributedClient { 安全
// 超时时间网络
private static final int SESSION_TIMEOUT = 5000; app
// zookeeper server列表分布式
private String hosts = "localhost:4180,localhost:4181,localhost:4182"; this
private String groupNode = "locks"; spa
private String subNode = "sub"; 线程
private ZooKeeper zk;
// 当前client建立的子节点
private String thisPath;
// 当前client等待的子节点
private String waitPath;
private CountDownLatch latch = new CountDownLatch(1);
/**
* 链接zookeeper
*/
public void connectZookeeper() throws Exception {
zk = new ZooKeeper(hosts, SESSION_TIMEOUT, new Watcher() {
public void process(WatchedEvent event) {
try {
// 链接创建时, 打开latch, 唤醒wait在该latch上的线程
if (event.getState() == KeeperState.SyncConnected) {
latch.countDown();
}
// 发生了waitPath的删除事件
if (event.getType() == EventType.NodeDeleted && event.getPath().equals(waitPath)) {
doSomething();
}
} catch (Exception e) {
e.printStackTrace();
}
}
});
// 等待链接创建
latch.await();
// 建立子节点
thisPath = zk.create("/" + groupNode + "/" + subNode, null, Ids.OPEN_ACL_UNSAFE,
CreateMode.EPHEMERAL_SEQUENTIAL);
// wait一小会, 让结果更清晰一些
Thread.sleep(10);
// 注意, 没有必要监听"/locks"的子节点的变化状况
List<String> childrenNodes = zk.getChildren("/" + groupNode, false);
// 列表中只有一个子节点, 那确定就是thisPath, 说明client得到锁
if (childrenNodes.size() == 1) {
doSomething();
} else {
String thisNode = thisPath.substring(("/" + groupNode + "/").length());
// 排序
Collections.sort(childrenNodes);
int index = childrenNodes.indexOf(thisNode);
if (index == -1) {
// never happened
} else if (index == 0) {
// inddx == 0, 说明thisNode在列表中最小, 当前client得到锁
doSomething();
} else {
// 得到排名比thisPath前1位的节点
this.waitPath = "/" + groupNode + "/" + childrenNodes.get(index - 1);
// 在waitPath上注册监听器, 当waitPath被删除时, zookeeper会回调监听器的process方法
zk.getData(waitPath, true, new Stat());
}
}
}
private void doSomething() throws Exception {
try {
System.out.println("gain lock: " + thisPath);
Thread.sleep(2000);
// do something
} finally {
System.out.println("finished: " + thisPath);
// 将thisPath删除, 监听thisPath的client将得到通知
// 至关于释放锁
zk.delete(this.thisPath, -1);
}
}
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
new Thread() {
public void run() {
try {
DistributedClient dl = new DistributedClient();
dl.connectZookeeper();
} catch (Exception e) {
e.printStackTrace();
}
}
}.start();
}
Thread.sleep(Long.MAX_VALUE);
}
}

思考

思惟缜密的朋友可能会想到, 上述的方案并不安全. 假设某个client在得到锁以前挂掉了, 因为client建立的节点是ephemeral类型的, 所以这个节点也会被删除, 从而致使排在这个client以后的client提早得到了锁. 此时会存在多个client同时访问共享资源.
如何解决这个问题呢? 能够在接到waitPath的删除通知的时候, 进行一次确认, 确认当前的thisPath是否真的是列表中最小的节点.

// 发生了waitPath的删除事件
if (event.getType() == EventType.NodeDeleted && event.getPath().equals(waitPath)) {
// 确认thisPath是否真的是列表中的最小节点
List<String> childrenNodes = zk.getChildren("/" + groupNode, false);
String thisNode = thisPath.substring(("/" + groupNode + "/").length());
// 排序
Collections.sort(childrenNodes);
int index = childrenNodes.indexOf(thisNode);
if (index == 0) {
// 确实是最小节点
doSomething();
} else {
// 说明waitPath是因为出现异常而挂掉的
// 更新waitPath
waitPath = "/" + groupNode + "/" + childrenNodes.get(index - 1);
// 从新注册监听, 并判断此时waitPath是否已删除
if (zk.exists(waitPath, true) == null) {
doSomething();
}
}
}

另外, 因为thisPath和waitPath这2个成员变量会在多个线程中访问, 最好将他们声明为volatile, 以防止出现线程可见性问题.

另外一种思路

下面介绍一种更简单, 可是不怎么推荐的解决方案.
每一个client在getChildren的时候, 注册监听子节点的变化. 当子节点的变化通知到来时, 再一次经过getChildren获取子节点列表, 判断thisPath是不是列表中的最小节点, 若是是, 则执行资源访问逻辑.

public class DistributedClient2 {
// 超时时间
private static final int SESSION_TIMEOUT = 5000;
// zookeeper server列表
private String hosts = "localhost:4180,localhost:4181,localhost:4182";
private String groupNode = "locks";
private String subNode = "sub";
private ZooKeeper zk;
// 当前client建立的子节点
private volatile String thisPath;
private CountDownLatch latch = new CountDownLatch(1);
/**
* 链接zookeeper
*/
public void connectZookeeper() throws Exception {
zk = new ZooKeeper(hosts, SESSION_TIMEOUT, new Watcher() {
public void process(WatchedEvent event) {
try {
// 链接创建时, 打开latch, 唤醒wait在该latch上的线程
if (event.getState() == KeeperState.SyncConnected) {
latch.countDown();
}
// 子节点发生变化
if (event.getType() == EventType.NodeChildrenChanged && event.getPath().equals("/" + groupNode)) {
// thisPath是不是列表中的最小节点
List<String> childrenNodes = zk.getChildren("/" + groupNode, true);
String thisNode = thisPath.substring(("/" + groupNode + "/").length());
// 排序
Collections.sort(childrenNodes);
if (childrenNodes.indexOf(thisNode) == 0) {
doSomething();
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
});
// 等待链接创建
latch.await();
// 建立子节点
thisPath = zk.create("/" + groupNode + "/" + subNode, null, Ids.OPEN_ACL_UNSAFE,
CreateMode.EPHEMERAL_SEQUENTIAL);
// wait一小会, 让结果更清晰一些
Thread.sleep(10);
// 监听子节点的变化
List<String> childrenNodes = zk.getChildren("/" + groupNode, true);
// 列表中只有一个子节点, 那确定就是thisPath, 说明client得到锁
if (childrenNodes.size() == 1) {
doSomething();
}
}
/**
* 共享资源的访问逻辑写在这个方法中
*/
private void doSomething() throws Exception {
try {
System.out.println("gain lock: " + thisPath);
Thread.sleep(2000);
// do something
} finally {
System.out.println("finished: " + thisPath);
// 将thisPath删除, 监听thisPath的client将得到通知
// 至关于释放锁
zk.delete(this.thisPath, -1);
}
}
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
new Thread() {
public void run() {
try {
DistributedClient2 dl = new DistributedClient2();
dl.connectZookeeper();
} catch (Exception e) {
e.printStackTrace();
}
}
}.start();
}
Thread.sleep(Long.MAX_VALUE);
}
}

为何不推荐这个方案呢? 是由于每次子节点的增长和删除都要广播给全部client, client数量很少时还看不出问题. 若是存在不少client, 那么就可能致使广播风暴--过多的广播通知阻塞了网络. 使用第一个方案, 会使得通知的数量大大降低. 固然第一个方案更复杂一些, 复杂的方案同时也意味着更容易引进bug.

ZooKeeper示例 分布式锁

场景描述

思路

实现

思考

另外一种思路

ZooKeeper示例分布式锁