分布式利器Zookeeper（二）:分布式锁

在《分布式利器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。

连接ZK的方式

说明：

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

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

对于事件（WatchedEvent）而言，有状态以及类型。

事件状态及事件类型

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

create

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

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

get/delete

这里需要注意的是，原生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回调。

下面我们来直接看代码：

提供Watcher的实现

提供process方法

main

一定得注意的是，监控该节点和监控该节点的子节点是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实现分布式锁的代码。不早啦，上班去啦！