一、分布式锁介绍
分布式锁主要用于在分布式环境中保护跨进程、跨主机、跨网络的共享资源实现互斥访问，以达到保证数据的一致性。
实现分布式锁目前有三种流行方案，分别为基于数据库、Redis、Zookeeper的方案，其中前两种方案网络上有很多资料可以参考，本文不做展开。我们来看下使用Zookeeper如何实现分布式锁。
什么是Zookeeper？
Zookeeper（业界简称zk）是一种提供配置管理、分布式协同以及命名的中心化服务，这些提供的功能都是分布式系统中非常底层且必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。因此zookeeper提供了这些功能，开发者在zookeeper之上构建自己的各种分布式系统。
虽然zookeeper的实现比较复杂，但是它提供的模型抽象却是非常简单的。Zookeeper提供一个多层级的节点命名空间（节点称为znode），每个节点都用一个以斜杠（/）分隔的路径表示，而且每个节点都有父节点（根节点除外），非常类似于文件系统。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
而为了保证高可用，zookeeper需要以集群形态来部署，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。客户端在使用zookeeper时，需要知道集群机器列表，通过与集群中的某一台机器建立TCP连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。
架构简图如下所示：
zookeeper
客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。
如何使用zookeeper实现分布式锁？
在描述算法流程之前，先看下zookeeper中几个关于节点的有趣的性质：
-
有序节点：假如当前有一个父节点为/lock，我们可以在这个父节点下面创建子节点；zookeeper提供了一个可选的有序特性，例如我们可以创建子节点“/lock/node-”并且指明有序，那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号，也就是说如果是第一个创建的子节点，那么生成的子节点为/lock/node-0000000000，下一个节点则为/lock/node-0000000001，依次类推。
-
临时节点：客户端可以建立一个临时节点，在会话结束或者会话超时后，zookeeper会自动删除该节点。
-
事件监听：在读取数据时，我们可以同时对节点设置事件监听，当节点数据或结构变化时，zookeeper会通知客户端。当前zookeeper有如下四种事件：1）节点创建；2）节点删除；3）节点数据修改；4）子节点变更。
下面描述使用zookeeper实现分布式锁的算法流程，假设锁空间的根节点为/lock：
-
客户端连接zookeeper，并在/lock下创建临时的且有序的子节点，第一个客户端对应的子节点为/lock/lock-0000000000，第二个为/lock/lock-0000000001，以此类推。
-
客户端获取/lock下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听/lock的子节点变更消息，获得子节点变更通知后重复此步骤直至获得锁；
-
执行业务代码；
-
完成业务流程后，删除对应的子节点释放锁。
步骤1中创建的临时节点能够保证在故障的情况下锁也能被释放，考虑这么个场景：假如客户端a当前创建的子节点为序号最小的节点，获得锁之后客户端所在机器宕机了，客户端没有主动删除子节点；如果创建的是永久的节点，那么这个锁永远不会释放，导致死锁；由于创建的是临时节点，客户端宕机后，过了一定时间zookeeper没有收到客户端的心跳包判断会话失效，将临时节点删除从而释放锁。
另外细心的朋友可能会想到，在步骤2中获取子节点列表与设置监听这两步操作的原子性问题，考虑这么个场景：客户端a对应子节点为/lock/lock-0000000000，客户端b对应子节点为/lock/lock-0000000001，客户端b获取子节点列表时发现自己不是序号最小的，但是在设置监听器前客户端a完成业务流程删除了子节点/lock/lock-0000000000，客户端b设置的监听器岂不是丢失了这个事件从而导致永远等待了？这个问题不存在的。因为zookeeper提供的API中设置监听器的操作与读操作是原子执行的，也就是说在读子节点列表时同时设置监听器，保证不会丢失事件。
最后，对于这个算法有个极大的优化点：假如当前有1000个节点在等待锁，如果获得锁的客户端释放锁时，这1000个客户端都会被唤醒，这种情况称为“羊群效应”；在这种羊群效应中，zookeeper需要通知1000个客户端，这会阻塞其他的操作，最好的情况应该只唤醒新的最小节点对应的客户端。应该怎么做呢？在设置事件监听时，每个客户端应该对刚好在它之前的子节点设置事件监听，例如子节点列表为/lock/lock-0000000000、/lock/lock-0000000001、/lock/lock-0000000002，序号为1的客户端监听序号为0的子节点删除消息，序号为2的监听序号为1的子节点删除消息。
zookeeper学习中
所以调整后的分布式锁算法流程如下：
-
客户端连接zookeeper，并在/lock下创建临时的且有序的子节点，第一个客户端对应的子节点为/lock/lock-0000000000，第二个为/lock/lock-0000000001，以此类推；
-
客户端获取/lock下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听刚好在自己之前一位的子节点删除消息，获得子节点变更通知后重复此步骤直至获得锁；
-
执行业务代码；
-
完成业务流程后，删除对应的子节点释放锁。
二、架构介绍
在介绍使用Zookeeper实现分布式锁之前，首先看当前的系统架构图
解释： 左边的整个区域表示一个Zookeeper集群，locker是Zookeeper的一个持久节点，node_1、node_2、node_3是locker这个持久节点下面的临时顺序节点。client_1、client_2、client_n表示多个客户端，Service表示需要互斥访问的共享资源。
三、分布式锁获取思路
1．获取分布式锁的总体思路
在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客户端调用createNode方法在locker下创建临时顺序节点，
然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。客户端获取到所有的子节点path之后，如果发现自己在之
前创建的子节点序号最小，那么就认为该客户端获取到了锁。如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，
此时客户端需要找到比自己小的那个节点，然后对其调用exist()方法，同时对其注册事件监听器。之后，让这个被关注的节点删除，则客户端的Watcher会
收到相应通知，此时再次判断自己创建的节点是否是locker子节点中序号最小的，如皋是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个
节点并注册监听。当前这个过程中还需要许多的逻辑判断。
2．获取分布式锁的核心算法流程
下面同个一个流程图来分析获取分布式锁的完整算法，如下：
解释：客户端A要获取分布式锁的时候首先到locker下创建一个临时顺序节点（node_n），然后立即获取locker下的所有（一级）子节点。
此时因为会有多个客户端同一时间争取锁，因此locker下的子节点数量就会大于1。对于顺序节点，特点是节点名称后面自动有一个数字编号，
先创建的节点数字编号小于后创建的，因此可以将子节点按照节点名称后缀的数字顺序从小到大排序，这样排在第一位的就是最先创建的顺序节点，
此时它就代表了最先争取到锁的客户端！此时判断最小的这个节点是否为客户端A之前创建出来的node_n，如果是则表示客户端A获取到了锁，
如果不是则表示锁已经被其它客户端获取，因此客户端A要等待它释放锁，也就是等待获取到锁的那个客户端B把自己创建的那个节点删除。
此时就通过监听比node_n次小的那个顺序节点的删除事件来知道客户端B是否已经释放了锁，如果是，此时客户端A再次获取locker下的所有子节点，
再次与自己创建的node_n节点对比，直到自己创建的node_n是locker的所有子节点中顺序号最小的，此时表示客户端A获取到了锁！
四、基于Zookeeper的分布式锁的代码实现
1．定义分布式锁接口
定义的分布式锁接口如下：
| public interface DistributedLock {
/**获取锁，如果没有得到就等待*/ public void acquire() throws Exception;
/** * 获取锁，直到超时 * @param time超时时间 * @param unit time参数的单位 * @return是否获取到锁 * @throws Exception */ public boolean acquire (long time, TimeUnit unit) throws Exception;
/** * 释放锁 * @throws Exception */ public void release() throws Exception; } |
2．定义一个简单的互斥锁
定义一个互斥锁类，实现以上定义的锁接口，同时继承一个基类BaseDistributedLock，该基类主要用于与Zookeeper交互，
包含一个尝试获取锁的方法和一个释放锁。
| /**锁接口的具体实现，主要借助于继承的父类BaseDistributedLock来实现的接口方法 * 该父类是基于Zookeeper实现分布式锁的具体细节实现*/ public class SimpleDistributedLockMutex extends BaseDistributedLock implements DistributedLock { /*用于保存Zookeeper中实现分布式锁的节点，如名称为locker：/locker， *该节点应该是持久节点，在该节点下面创建临时顺序节点来实现分布式锁 */ private final String basePath;
/*锁名称前缀，locker下创建的顺序节点例如都以lock-开头，这样便于过滤无关节点 *这样创建后的节点类似：lock-00000001，lock-000000002*/ private staticfinal String LOCK_NAME ="lock-";
/*用于保存某个客户端在locker下面创建成功的顺序节点，用于后续相关操作使用（如判断）*/ private String ourLockPath;
/** * 用于获取锁资源，通过父类的获取锁方法来获取锁 * @param time获取锁的超时时间 * @param unit time的时间单位 * @return是否获取到锁 * @throws Exception */ private boolean internalLock (long time, TimeUnit unit) throws Exception { //如果ourLockPath不为空则认为获取到了锁，具体实现细节见attemptLock的实现 ourLockPath = attemptLock(time, unit); return ourLockPath !=null; }
/** * 传入Zookeeper客户端连接对象，和basePath * @param client Zookeeper客户端连接对象 * @param basePath basePath是一个持久节点 */ public SimpleDistributedLockMutex(ZkClientExt client, String basePath){ /*调用父类的构造方法在Zookeeper中创建basePath节点，并且为basePath节点子节点设置前缀 *同时保存basePath的引用给当前类属性*/ super(client,basePath,LOCK_NAME); this.basePath = basePath; }
/**获取锁，直到超时，超时后抛出异常*/ public void acquire() throws Exception { //-1表示不设置超时时间，超时由Zookeeper决定 if (!internalLock(-1,null)){ throw new IOException("连接丢失!在路径:'"+basePath+"'下不能获取锁!"); } }
/** * 获取锁，带有超时时间 */ public boolean acquire(long time, TimeUnit unit) throws Exception { return internalLock(time, unit); }
/**释放锁*/ public void release()throws Exception { releaseLock(ourLockPath); } } |
3. 分布式锁的实现细节
获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于Zookeeper实现分布式锁的细节。
public class BaseDistributedLock {
private final ZkClientExt client;
private final String path;
private final String basePath;
private final String lockName;
private static final Integer MAX_RETRY_COUNT = 10;
public BaseDistributedLock(ZkClientExt client, String path, String lockName){
this.client = client;
this.basePath = path;
this.path = path.concat("/").concat(lockName);
this.lockName = lockName;
}
private void deleteOurPath(String ourPath) throws Exception{
client.delete(ourPath);
}
private String createLockNode(ZkClient client, String path) throws Exception{
return client.createEphemeralSequential(path, null);
}
/**
* 获取锁的核心方法
* @param startMillis
* @param millisToWait
* @param ourPath
* @return
* @throws Exception
*/
private boolean waitToLock(long startMillis, Long millisToWait, String ourPath) throws Exception{
boolean haveTheLock = false;
boolean doDelete = false;
try{
while ( !haveTheLock ) {
//该方法实现获取locker节点下的所有顺序节点，并且从小到大排序
List<String> children = getSortedChildren();
String sequenceNodeName = ourPath.substring(basePath.length()+1);
//计算刚才客户端创建的顺序节点在locker的所有子节点中排序位置，如果是排序为0，则表示获取到了锁
int ourIndex = children.indexOf(sequenceNodeName);
/*如果在getSortedChildren中没有找到之前创建的[临时]顺序节点，这表示可能由于网络闪断而导致
*Zookeeper认为连接断开而删除了我们创建的节点，此时需要抛出异常，让上一级去处理
*上一级的做法是捕获该异常，并且执行重试指定的次数 见后面的 attemptLock方法 */
if ( ourIndex<0 ){
throw new ZkNoNodeException("节点没有找到: " + sequenceNodeName);
}
//如果当前客户端创建的节点在locker子节点列表中位置大于0，表示其它客户端已经获取了锁
//此时当前客户端需要等待其它客户端释放锁，
boolean isGetTheLock = ourIndex == 0;
//如何判断其它客户端是否已经释放了锁？从子节点列表中获取到比自己次小的哪个节点，并对其建立监听
String pathToWatch = isGetTheLock ? null : children.get(ourIndex - 1);
if ( isGetTheLock ){
haveTheLock = true;
}else{
//如果次小的节点被删除了，则表示当前客户端的节点应该是最小的了，所以使用CountDownLatch来实现等待
String previousSequencePath = basePath .concat( "/" ) .concat( pathToWatch );
final CountDownLatch latch = new CountDownLatch(1);
final IZkDataListener previousListener = new IZkDataListener() {
//次小节点删除事件发生时，让countDownLatch结束等待
//此时还需要重新让程序回到while，重新判断一次！
public void handleDataDeleted(String dataPath) throws Exception {
latch.countDown();
}
public void handleDataChange(String dataPath, Object data) throws Exception {
// ignore
}
};
try{
//如果节点不存在会出现异常
client.subscribeDataChanges(previousSequencePath, previousListener);
if ( millisToWait != null ){
millisToWait -= (System.currentTimeMillis() - startMillis);
startMillis = System.currentTimeMillis();
if ( millisToWait <= 0 ){
doDelete = true; // timed out - delete our node
break;
}
latch.await(millisToWait, TimeUnit.MICROSECONDS);
}else{
latch.await();
}
}catch ( ZkNoNodeException e ){
//ignore
}finally{
client.unsubscribeDataChanges(previousSequencePath, previousListener);
}
}
}
}catch ( Exception e ){
//发生异常需要删除节点
doDelete = true;
throw e;
}finally{
//如果需要删除节点
if ( doDelete ){
deleteOurPath(ourPath);
}
}
return haveTheLock;
}
private String getLockNodeNumber(String str, String lockName) {
int index = str.lastIndexOf(lockName);
if ( index >= 0 ){
index += lockName.length();
return index <= str.length() ? str.substring(index) : "";
}
return str;
}
private List<String> getSortedChildren() throws Exception {
try{
List<String> children = client.getChildren(basePath);
Collections.sort(
children,
new Comparator<String>(){
public int compare(String lhs, String rhs){
return getLockNodeNumber(lhs, lockName).compareTo(getLockNodeNumber(rhs, lockName));
}
}
);
return children;
}catch(ZkNoNodeException e){
client.createPersistent(basePath, true);
return getSortedChildren();
}
}
protected void releaseLock(String lockPath) throws Exception{
deleteOurPath(lockPath);
}
protected String attemptLock(long time, TimeUnit unit) throws Exception{
final long startMillis = System.currentTimeMillis();
final Long millisToWait = (unit != null) ? unit.toMillis(time) : null;
String ourPath = null;
boolean hasTheLock = false;
boolean isDone = false;
int retryCount = 0;
//网络闪断需要重试一试
while ( !isDone ){
isDone = true;
try{
//createLockNode用于在locker（basePath持久节点）下创建客户端要获取锁的[临时]顺序节点
ourPath = createLockNode(client, path);
/**
* 该方法用于判断自己是否获取到了锁，即自己创建的顺序节点在locker的所有子节点中是否最小
* 如果没有获取到锁，则等待其它客户端锁的释放，并且稍后重试直到获取到锁或者超时
*/
hasTheLock = waitToLock(startMillis, millisToWait, ourPath);
}catch ( ZkNoNodeException e ){
if ( retryCount++ < MAX_RETRY_COUNT ){
isDone = false;
}else{
throw e;
}
}
}
if ( hasTheLock ){
return ourPath;
}
return null；
｝
扫一扫
2997
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
