zookeeper分布式锁

Zookeeper

基于使用Zookeeper实现分布式锁相信大家都非常熟悉，他是基于Zookeeper中的临时顺序节点来实现的。

临时顺序性节点 + ZAB协议

原理：Zookeeper中的ZNode有持久性节点和临时节点，临时节点的生命周期跟客户端的Session是绑定的。当客户端失去连接之后，所创建的临时节点也会全部删除。

锁的获取：就是全部客户端去Zookeeper创建同一个节点，看谁成功创建，谁就获得了锁。

锁的释放：客户端自行删除节点，或者客户端和服务器超时之后强制释放。

Zookeeper是一个CP中间件，采用的是ZAB（Zookeeper Atomic Broadcast）分布式一致性协议。所以他可以很好的控制并发情况下节点创建的唯一性。

Zookeeper是一个非常可靠的分布式锁实现方案，缺点就是会引入第三方的中间件使得系统架构会变重。需要根据自己的业务数据量来判断是否上Zookeeper。

———————

Zookeeper 里面的节点可以分为两大类，一种是临时节点，一种是持久化节点。

临时节点，指的是节点创建后，如果创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接)，那么节点就会被删除。

持久化节点指的是节点创建后，即使创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接)，节点也不会被删除，只有客户端主动发起删除节点的请求，节点才会被删除。

另外还有一种节点叫做有序节点，这种节点在创建时会有一个序号，这个序号是自增的。有序节点既可以是有序临时节点，也可以是有序持久化节点。

临时顺序节点实现分布式锁

在每一个节点下面创建临时顺序节点（EPHEMERAL_SEQUENTIAL）类型，新的子节点后面，会加上一个次序编号，而这个生成的次序编号，是上一个生成的次序编号加一。

例如，有一个用于发号的节点“/test/lock”为父亲节点，可以在这个父节点下面创建相同前缀的临时顺序子节点，假定相同的前缀为“/test/lock/seq-”。第一个创建的子节点基本上应该为/test/lock/seq-0000000000，下一个节点则为/test/lock/seq-0000000001，依次类推。

一个ZooKeeper分布式锁，首先需要创建一个父节点，尽量是持久节点（PERSISTENT类型），然后每个要获得锁的线程，都在这个节点下创建个临时顺序节点。由于ZK节点，是按照创建的次序，依次递增的。

为了确保公平，可以简单的规定：编号最小的那个节点，表示获得了锁。所以，每个线程在尝试占用锁之前，首先判断自己是排号是不是当前最小，如果是，则获取锁，也就是谁先创建的节点，谁获取锁。

 ZooKeeper的节点监听机制，可以保障占有锁的传递有序而且高效。

每个线程抢占锁之前，先尝试创建自己的ZNode。同样，释放锁的时候，就需要删除创建的Znode。创建成功后，如果不是排号最小的节点，就处于等待通知的状态。等谁的通知呢？不需要其他人，只需要等前一个Znode的通知就可以了。前一个Znode删除的时候，会触发Znode事件，当前节点能监听到删除事件，就是轮到了自己占有锁的时候。第一个通知第二个、第二个通知第三个，击鼓传花似的依次向后。

ZooKeeper的节点监听机制，能够非常完美地实现这种击鼓传花似的信息传递。具体的方法是，每一个等通知的Znode节点，只需要监听（linsten）或者监视（watch）排号在自己前面那个，而且紧挨在自己前面的那个节点，就能收到其删除事件了。
只要上一个节点被删除了，就进行再一次判断，看看自己是不是序号最小的那个节点，如果是，自己就获得锁。

ZooKeeper的内部优越的机制，能保证由于网络异常或者其他原因，集群中占用锁的客户端失联时，锁能够被有效释放。一旦占用Znode锁的客户端与ZooKeeper集群服务器失去联系，这个临时Znode也将自动删除。排在它后面的那个节点，也能收到删除事件，从而获得锁。正是由于这个原因，在创建取号节点的时候，尽量创建临时znode节点