《分布式利器Zookeeper(一)》中对ZK进行了初步的介绍以及搭建ZK集群环境,本篇博客将涉及的话题是:基于原生API方式操作ZK,Watch机制,分布式锁思路探讨等。

原生API操作ZK 

什么叫原生API操作ZK呢?实际上,利用zookeeper.jar这样的就是基于原生的API方式操作ZK,因为这个原生API使用起来并不是让人很舒服,于是出现了zkclient这种方式,以至到后来基于Curator框架,让人使用ZK更加方便。有一句话,Guava is to JAVA what Curator is to Zookeeper。

wKioL1kYVjfhN9n6AACbzYCLNZw148.png

说明:

在初始化Zookeeper时,有多种构造方法可以选择,有3个参数是必备的:connectionString(多个ZK SERVER之间以,分隔),sessionTimeout(就是zoo.cfg中的tickTime),Watcher(事件处理通知器)。

需要注意的是ZK的连接是异步的,因此我们需要CountDownLatch来帮助我们确保ZK初始化完成。

对于事件(WatchedEvent)而言,有状态以及类型。


wKiom1kYVn7SSNADAACrBQ_2rok667.png


下面,我们来看一看基于原生API方式的增删改查:

wKiom1kYVqrSP0fsAAB3xwG-ZeU870.png

注意,节点有2大类型,持久化节点、临时节点。在此基础上,又可以分为持久化顺序节点(PERSISTENT_SEQUENTIAL)、临时顺序节点(EPHEMERAL_SEQUENTIAL)。

节点类型只支持byte[],也就是说我们是无法直接给一个对象给ZK,让ZK帮助我们完成序列化操作的!


wKioL1kYVtzS3X_UAACAQWawRA0357.png


这里需要注意的是,原生API对于ZK的操作其实是分为同步和异步2种方式的。

rc表示return code,就是返回码,0即为正常。

path是传入API的参数,ctx也是传入的参数。

注意在删除过程中,是需要版本检查的,所以我们一般提供-1跳过版本检查机制。


Watch机制

ZK有watch事件,是一次性触发的。当watch监控的数据发生变化,会通知设置了该监控的client,即watcher。Zookeeper的watch是有自己的一些特性的:

一次性:请牢记,just watch one time! 因为ZK的监控是一次性的,所以每次必须设置监控。

轻量:WatchedEvent是ZK进行watch通知的最小单元,整个数据结构包含:事件状态、事件类型、节点路径。注意ZK只是通知client节点的数据发生了变化,而不会直接提供具体的数据内容。

客户端串行执行机制:注意客户端watch回调的过程是一个串行同步的过程,这为我们保证了顺序,我们也应该意识到不能因一个watch的回调处理逻辑而影响了整个客户端的watch回调。

下面我们来直接看代码:

wKioL1kYVybw4SM3AABvn5hF46I719.png


wKioL1kYV0GzhOIUAADI24gEhtE694.png


wKioL1kYV1-CsR2kAAEFZmu1wNs860.png

一定得注意的是,监控该节点和监控该节点的子节点是2码子事。

比如exists(path,true)监控的就是该path节点的create/delete/setData;getChildren(path,watcher)监控的就是该path节点下的子节点的变化(子节点的创建、修改、删除都会监控到,而且事件类型都是一样的,想一想如何区分呢?给一个我的思路,就是我们得先有该path下的子节点的列表,然后watch触发后,我们对比下该path下面的子节点SIZE大小及内容,就知道是增加的是哪个子节点,删除的是哪个子节点了!)

getChildren(path,true)和getChildren(path,watcher)有什么区别?前者是沿用上下文中的Watcher,而后者则是可以设置一个新的Watcher的!(因此,要想做到一直监控,那么就有2种方式,一个是注意每次设置成true,或者干脆每次设置一个新的Watcher)

从上面的讨论中,你大概能了解到原生的API其实功能上还不是很强大,有些还得我们去操心,到后面为大家介绍Curator框架,会有更好的方式进行处理。


分布式锁思路

首先,我们不谈Zookeeper是如何帮助我们处理分布式锁的,而是先来想一想,什么是分布式锁?为什么需要分布式锁?有哪些场景呢?分布式锁的使用又有哪些注意的?分布式锁有什么特性呢?

说起锁,我们自然想到Java为我们提供的synchronized/Lock,但是这显然不够,因为这只能针对一个JVM中的多个线程对共享资源的操作。那么对于多台机器,多个进程对同一类资源进行操作的话,就是所谓分布式场景下的锁。

各个电商平台经常搞的“秒杀”活动需要对商品的库存进行保护、12306火车票也不能多卖,更不允许一张票被多个人买到、这样的场景就需要分布式锁对共享资源进行保护!

既然,Java在分布式场景下的锁已经无能为力,那么我们只能借助其他东西了!

我们的老朋友:DB

对,没错,我们能否借助DB来实现呢?要知道DB是有一些特点供我们利用的,比如DB本身就存在锁机制(表锁、行锁),唯一约束等等。

假设,我们的DB中有一张表T(id,methodname,ip,threadname,......),其中id为主键,methodname为唯一索引。

对于多台机器,每台机器上的多个线程而言,对一个方法method进行操作前,先select下T表中是否存在method这条记录,如果没有,就插入一条记录到T中。当然可能并发select,但是由于T表的唯一约束,使得只有一个请求能插入成功,即获得锁。至于释放锁,就是方法执行完毕后delete这条记录即可。

考虑一些问题:如果DB挂了,怎么办?如果由于一些因素,导致delete没有执行成功,那么这条记录会导致该方法再也不能被访问!为什么要先select,为什么不直接insert呢?性能如何呢?

为了避免单点,可以主备之间实现切换;为了避免死锁的产生,那么我们可以有一个定时任务,定期清理T表中的记录;先select后insert,其实是为了保证锁的可重入性,也就是说,如果一台IP上的某个线程获取了锁,那么它可以不用在释放锁的前提下,继续获得锁;性能上,如果大量的请求,将会对DB考验,这将成为瓶颈。

到这里,还有一个明显的问题,需要我们考虑:上述的方案,虽然保证了只会有一个请求获得锁,但其他请求都获取锁失败返回了,而没有进行锁等待!当然,我们可以通过重试机制,来实现阻塞锁,不过数据库本身的锁机制可以帮助我们完成。别忘了select ... for update这种阻塞式的行锁机制,commit进行锁的释放。而且对于for update这种独占锁,如果长时间不提交释放,会一直占用DB连接,连接爆了,就跪了!

不说了,老朋友也只能帮我们到这里了!


我们的新朋友:Redis or 其他分布式缓存(Tair/...)

既然说是缓存,相较DB,有更好的性能;既然说是分布式,当然避免了单点问题;

比如,用Redis作为分布式锁的setnx,这里我就不细说了,总之分布式缓存需要特别注意的是缓存的失效时间。(有效时间过短,搞不好业务还没有执行完毕,就释放锁了;有效时间过长,其他线程白白等待,浪费了时间,拖慢了系统处理速度)

看Zookeeper是如何帮助我们实现分布式锁

Zookeeper中临时顺序节点的特性:

第一,节点的生命周期和client回话绑定,即创建节点的客户端回话一旦失效,那么这个节点就会被删除。(临时性)

第二,每个父节点都会维护子节点创建的先后顺序,自动为子节点分配一个整形数值,以后缀的形式自动追加到节点名称中,作为这个节点最终的节点名称。(顺序性)

那么,基于临时顺序节点的特性,Zookeeper实现分布式锁的一般思路如下:

1.client调用create()方法创建“/root/lock_”节点,注意节点类型是EPHEMERAL_SEQUENTIAL

2.client调用getChildren("/root/lock_",watch)来获取所有已经创建的子节点,并同时在这个节点上注册子节点变更通知的Watcher

3.客户端获取到所有子节点Path后,如果发现自己在步骤1中创建的节点是所有节点中最小的,那么就认为这个客户端获得了锁

4.如果在步骤3中,发现不是最小的,那么等待,直到下次子节点变更通知的时候,在进行子节点的获取,判断是否获取到锁

5.释放锁也比较容易,就是删除自己创建的那个节点即可

上面的这种思路,在集群规模很大的情况下,会出现“羊群效应”(Herd Effect):

在上面的分布式锁的竞争中,有一个细节,就是在getChildren上注册了子节点变更通知Watcher,这有什么问题么?这其实会导致客户端大量重复的运行,而且绝大多数的运行结果都是判断自己并非是序号最小的节点,从而继续等待下一次通知,也就是很多客户端做了很多无用功。更加要命的是,在集群规模很大的情况下,这显然会对Server的性能造成影响,而且一旦同一个时间,多个客户端断开连接,服务器会向其余客户端发送大量的事件通知,这就是所谓的羊群效应!

出现这个问题的根源,其实在于,上述的思路并没有找准客户端的“痛点”:

客户端的核心诉求在于判断自己是否是最小的节点,所以说每个节点的创建者其实不用关心所有的节点变更,它真正关心的应该是比自己序号小的那个节点是否存在!

1.client调用create()方法创建“/root/lock_”节点,注意节点类型是EPHEMERAL_SEQUENTIAL

2.client调用getChildren("/root/lock_",false)来获取所有已经创建的子节点,这里并不注册任何Watcher

3.客户端获取到所有子节点Path后,如果发现自己在步骤1中创建的节点是所有节点中最小的,那么就认为这个客户端获得了锁

4.如果在步骤3中,发现不是最小的,那么找到比自己小的那个节点,然后对其调用exist()方法注册事件监听

5.之后一旦这个被关注的节点移除,客户端会收到相应的通知,这个时候客户端需要再次调用getChildren("/root/lock_",false)来确保自己是最小的节点,然后进入步骤3

OK,talk is cheap show me the code,下一篇文章会为大家带来Zookeeper实现分布式锁的代码。