分布式锁(3)-基于ZooKeeper实现

 

引言

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

ZooKeeper的架构通过冗余服务实现高可用性。因此,如果第一次无应答,客户端就可以询问另一台ZooKeeper主机。ZooKeeper节点将它们的数据存储于一个分层的命名空间,非常类似于一个文件系统或一个前缀树结构。客户端可以在节点读写,从而以这种方式拥有一个共享的配置服务。更新是全序的。

基于ZooKeeper分布式锁的流程

下面描述使用zookeeper实现分布式锁的算法流程:

  • 客户端连接zookeeper,并在/lock下创建临时的且有序的子节点,第一个客户端对应的子节点为/lock/lock-0000000000,第二个为/lock/lock-0000000001,以此类推;

  • 客户端获取/lock下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听刚好在自己之前一位的子节点删除消息,获得子节点变更通知后重复此步骤直至获得锁;

  • 执行业务代码;

  • 完成业务流程后,删除对应的子节点释放锁。

具体实现

虽然zookeeper原生客户端暴露的API已经非常简洁了,但是实现一个分布式锁还是比较麻烦的…我们可以直接使用curator这个开源项目提供的zookeeper分布式锁实现。

		<dependency>
			<groupId>org.apache.curator</groupId>
			<artifactId>curator-recipes</artifactId>
			<version>4.0.0</version>
		</dependency>

 

package com.qibo.base.controller.zookeeper.lock;

import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ZkLockController {

	@RequestMapping("/zkLock")
	public void zkLock() {
		// 创建zookeeper的客户端

		RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
		CuratorFramework client = CuratorFrameworkFactory.newClient("192.168.10.10:2181", retryPolicy);
		client.start();

		// 创建分布式锁, 锁空间的根节点路径为/curator/lock
		InterProcessMutex mutex = new InterProcessMutex(client, "/curator/lock");
		try {
			// 1、获得了锁, 进行业务流程
			mutex.acquire();

			// 2、获得了锁, 进行业务流程
			// to do ...

			// 3、完成业务流程, 释放锁
			mutex.release();
		} catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		// 关闭客户端
		client.close();
	}

}

可以看到关键的核心操作就只有mutex.acquire()和mutex.release(),简直太方便了!

zkCli.sh

源码分析

下面来分析下获取锁的源码实现。acquire的方法如下:

/*

* 获取锁,当锁被占用时会阻塞等待,这个操作支持同线程的可重入(也就是重复获取锁),acquire的次数需要与release的次数相同。

* @throws Exception ZK errors, connection interruptions

*/

@Override

public void acquire() throws Exception

{

if ( !internalLock(-1, null) )

{

throw new IOException("Lost connection while trying to acquire lock: " + basePath);

}

}

这里有个地方需要注意,当与zookeeper通信存在异常时,acquire会直接抛出异常,需要使用者自身做重试策略。代码中调用了internalLock(-1, null),参数表明在锁被占用时永久阻塞等待。internalLock的代码如下:

private boolean internalLock(long time, TimeUnit unit) throws Exception

{

//这里处理同线程的可重入性,如果已经获得锁,那么只是在对应的数据结构中增加acquire的次数统计,直接返回成功

Thread currentThread = Thread.currentThread();

LockData lockData = threadData.get(currentThread);

if ( lockData != null )

{

// re-entering

lockData.lockCount.incrementAndGet();

return true;

}

//这里才真正去zookeeper中获取锁

String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());

if ( lockPath != null )

{

//获得锁之后,记录当前的线程获得锁的信息,在重入时只需在LockData中增加次数统计即可

LockData newLockData = new LockData(currentThread, lockPath);

threadData.put(currentThread, newLockData);

return true;

}

//在阻塞返回时仍然获取不到锁,这里上下文的处理隐含的意思为zookeeper通信异常

return false;

}

代码中增加了具体注释,不做展开。看下zookeeper获取锁的具体实现:

String attemptLock(long time, TimeUnit unit, byte[] lockNodeBytes) throws Exception

{

//参数初始化,此处省略

//...

//自旋获取锁

while ( !isDone )

{

isDone = true;

try

{

//在锁空间下创建临时且有序的子节点

ourPath = driver.createsTheLock(client, path, localLockNodeBytes);

//判断是否获得锁(子节点序号最小),获得锁则直接返回,否则阻塞等待前一个子节点删除通知

hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath);

}

catch ( KeeperException.NoNodeException e )

{

//对于NoNodeException,代码中确保了只有发生session过期才会在这里抛出NoNodeException,因此这里根据重试策略进行重试

if ( client.getZookeeperClient().getRetryPolicy().allowRetry(retryCount++, System.currentTimeMillis() - startMillis, RetryLoop.getDefaultRetrySleeper()) )

{

isDone = false;

}

else

{

throw e;

}

}

}

//如果获得锁则返回该子节点的路径

if ( hasTheLock )

{

return ourPath;

}

return null;

}

上面代码中主要有两步操作:

  • driver.createsTheLock:创建临时且有序的子节点,里面实现比较简单不做展开,主要关注几种节点的模式:1)PERSISTENT(永久);2)PERSISTENT_SEQUENTIAL(永久且有序);3)EPHEMERAL(临时);4)EPHEMERAL_SEQUENTIAL(临时且有序)。

  • internalLockLoop:阻塞等待直到获得锁。

看下internalLockLoop是怎么判断锁以及阻塞等待的,这里删除了一些无关代码,只保留主流程:

//自旋直至获得锁

while ( (client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock )

{

//获取所有的子节点列表,并且按序号从小到大排序

List<String> children = getSortedChildren();

//根据序号判断当前子节点是否为最小子节点

String sequenceNodeName = ourPath.substring(basePath.length() + 1); // +1 to include the slash

PredicateResults predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);

if ( predicateResults.getsTheLock() )

{

//如果为最小子节点则认为获得锁

haveTheLock = true;

}

else

{

//否则获取前一个子节点

String previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();

//这里使用对象监视器做线程同步,当获取不到锁时监听前一个子节点删除消息并且进行wait(),当前一个子节点删除(也就是锁释放)时,回调会通过notifyAll唤醒此线程,此线程继续自旋判断是否获得锁

synchronized(this)

{

try

{

//这里使用getData()接口而不是checkExists()是因为,如果前一个子节点已经被删除了那么会抛出异常而且不会设置事件监听器,而checkExists虽然也可以获取到节点是否存在的信息但是同时设置了监听器,这个监听器其实永远不会触发,对于zookeeper来说属于资源泄露

client.getData().usingWatcher(watcher).forPath(previousSequencePath);

//如果设置了阻塞等待的时间

if ( millisToWait != null )

{

millisToWait -= (System.currentTimeMillis() - startMillis);

startMillis = System.currentTimeMillis();

if ( millisToWait <= 0 )

{

doDelete = true; // 等待时间到达,删除对应的子节点

break;

}

//等待相应的时间

wait(millisToWait);

}

else

{

//永远等待

wait();

}

}

catch ( KeeperException.NoNodeException e )

{

//上面使用getData来设置监听器时,如果前一个子节点已经被删除那么会抛出NoNodeException,只需要自旋一次即可,无需额外处理

}

}

}

}

具体逻辑见注释,不再赘述。代码中设置的事件监听器,在事件发生回调时只是简单的notifyAll唤醒当前线程以重新自旋判断,比较简单不再展开。

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值