zookeeper 分布式锁_zookeeper实现分布式公平锁

1 首先聊一聊锁，比如lock锁或synchronized锁属于jvm锁，在服务器集群的环境下，比如f有二台服务器A、B，现在需要完成下单，高并发情况下由于网络等原因可能导致重试，对于用户的一笔订单（订单号001）可能发起了二次请求到后台，用lock锁或synchronized就不能保证不重复的问题，客户端请求通过ngnix（采用轮询）转发到A或者B服务器，这个是随机的，想想如果第一次客户端请求到A，第二次客户端请求到B，这时需要把查询订单和插入订单用lock锁起来，由于用的不是一把锁和没用锁一样，A、B根据订单号001都没查到订单，然后执行插入数据库，这时就导致对于同一笔用户订单001数据库有二条数据记录，那么如何在高并发场景下保证订单不重复的问题，需要将锁从jvm独立出来，让集群服务器A、B共享一把锁，需要采用分布式锁，常见的有实现方案有数据库、redis、zookeeper（上面举例只是单纯为了引出分布式锁），下面介绍zookeeper如何实现分布式锁。

2 zookeeper实现分布式锁，我们首先要知道zookeeper的四种数据类型：

a 持久节点

b 持久顺序节点

c 临时节点

d 临时顺序节点

这里说一下临时顺序节点，如下图，先创建的节点比后创建的节点顺号小（顺序性），当会话超时后临时节点自动删除（临时性），这二点由zookeeper保证，根据节点的顺序特性， 我们可以对节点排序，让先获取锁的线程先获取到锁，而临时性可以达到释放锁的效果，避免死锁发生。

zk创建的临时节点

3 整体实现思路,假设有3个线程同时请求获取锁 线程A，线程B,线程C

a 如果相处A创建的临时有序节点为 /lock/stock_lock0000204105，B创建的临时有序节点 为 /lock/stock_lock0000204104，C创建的临时有序节点为 /lock/stock_lock0000204106

b B线程创建的节点为最小节点，先获取到锁，A，C线程创建的节点不是最小节点,A线程监听B线程创建的节点/lock/stock_lock0000204104的删除事件，C线程监听A线程创建的节点

/lock/stock_lock0000204105的删除事件。一直循环获取、等待锁，直到获取到锁为止。

c 当B线程获取到锁，完成业务逻辑后会删除节点/lock/stock_lock0000204104，zookeeper会发送事件通知给A线程，A线程获取到锁，同理，A线程获取到锁完成业务逻辑后zookeeper会发送事件通知给C线程，这样C线程也获取到锁，根据以上逻辑流程实现的锁是公平锁和排他锁。

公平锁：先获取锁的线程先创建节点，先创建的节点序号小（zookeeper保证），然后先获取到锁。

排他锁：同一时只能有一个线程能获取到锁。

以下给出实现代码，代码有详细注释

public interface ZkLock {public String lock() throws Exception;public void unlock(String currentNode);
}

@Slf4jpublic abstract class abstractZkLock implements ZkLock {protected final String rootPath = "/lock";protected ZkClient zkClient = new ZkClient("127.0.0.1:2181");protected ThreadLocal<String> currentThreadLocal = new ThreadLocal<>();protected CountDownLatch countDownLatch;
@Overridepublic String lock() throws Exception {while (!tryLock()) {
String currentNode = currentThreadLocal.get();if (waitLock(currentNode)) {log.info(">>>节点{}获取锁成功！<<<", currentNode);currentThreadLocal.remove();return currentNode;
}
}// 第二种 前一个节点删除后才开始监听前一个节点删除事件，那么这个节点是永远都不会收到通知，当前节点为最小节点，直到超时后重新trylock 获取锁
String currentNode = currentThreadLocal.get();currentThreadLocal.remove();return currentNode;
}protected abstract boolean waitLock(String currentNode);protected abstract boolean tryLock();
@Overridepublic void unlock(String currentNode) {if (zkClient != null) {zkClient.delete(currentNode);log.info(">>>节点{}释放锁成功！<<<", currentNode);
}
}
}

@Slf4j
@Servicepublic class ZkLockImpl extends abstractZkLock implements ZkLock {
@PostConstructpublic void init() {if (!zkClient.exists(rootPath)) {zkClient.createPersistent(rootPath);
}
}
@Overrideprotected boolean waitLock(String currentNode) {
IZkDataListener iZkDataListener = new IZkDataListener() {
@Overridepublic void handleDataChange(String path, Object o) throws Exception {
}
@Overridepublic void handleDataDeleted(String path) throws Exception {log.info(">>>当前节点：{},前置节点：{}被删除事件通知！<<<", currentNode, path);countDownLatch.countDown();
}
};
String preNode = findPreNode(currentNode);if (!StringUtils.isEmpty(preNode)&&zkClient.exists(rootPath + "/" + preNode)){countDownLatch = new CountDownLatch(1);zkClient.subscribeDataChanges(rootPath + "/" + preNode, iZkDataListener);try {//这里是重点 有以下3种情况 //第一种 监听的前一个节点没有删除，等待100毫秒后超时仍然没有收到前一个节点删除的通知，await返回false，这时会重新trylock获取锁,直到获取到锁 //第二种 前一个节点删除后才开始监听前一个节点删除事件，那么这个节点是永远都不会收到通知，当前节点为最小节点，直到超时后重新trylock 获取锁 //第三种 监听的前一个节点没有删除，删除后当前节点收到通知后获取到锁,当前节点为最小节点，await返回truereturn countDownLatch.await(100, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {zkClient.unsubscribeDataChanges(rootPath + "/" + preNode, iZkDataListener);
}
}return false;
}
@Overrideprotected boolean tryLock(){
String currentNode = currentThreadLocal.get();if (StringUtils.isEmpty(currentNode)){
currentNode = zkClient.createEphemeralSequential(rootPath + "/stock_lock", "");currentThreadLocal.set(currentNode);
}return isFirstNode(currentNode);
}/* 获取当前节点的前一个节点，/lock/stock_lock0000204104，/lock/stock_lock0000204105，/lock/stock_lock0000204106 * /lock/stock_lock0000204104为/lock/stock_lock0000204105的前一个节点 * /lock/stock_lock0000204105为/lock/stock_lock0000204106 的前一个节点 */private String findPreNode(String currentNode) {
List<String> sortChildren = getSortChildren();int currentNodeIndex = Collections.binarySearch(sortChildren, currentNode);
String preNode = null;try {
preNode = sortChildren.get(currentNodeIndex - 1);
} catch (Exception e) {// http://log.info("当前节点的前一个节点已经删除！！！", e);
}return preNode;
}/* 判断当前节点是否是最小节点*/private boolean isFirstNode(String currentNode) {
List<String> sortChildren = getSortChildren();if (currentNode.equals(rootPath+"/"+sortChildren.get(0))){log.info(">>>节点{}获取锁成功！<<<", currentNode);return true;
}return false;
}/* 获取rootPath节点下的所有子节点*/private List<String> getSortChildren() {
List<String> children = zkClient.getChildren(rootPath);
Collections.sort(children);return children;
}
}

看看代码顺便可以理解一下ThreadLocal、CountDownLatch这2个对象的用法

以下用jmeter测试插入10000条数据

测试代码

刚好10000个请求

开始时间 2019-12-11 16:23:31

结束时间2019-12-11 16:42:07

总共耗时18:36算了一下插入一笔订单平均约0.1s,效率不怎么样，重要是思路，真要生产实现分布式锁建议采用redis。

完结，觉得有收获，可以点个赞！不足之处，望大佬指导！