java版是网上找来的，链接忘了。。。。。scala版基本是根据java版改的。。。。记录一下。。。也供参考学习
在分布式系统中，资源可能同时被多个客户端申请访问，因此保证数据访问的正确性和性能是分布式系统必须要考虑的问题。非分布式下我们通常是通过synchronize或lock，以及数据库锁(不限制非分布式和分布式)，而这两种多存在相应的弊端，synchronize或lock不能解决分布式系统，数据库锁在大量请求下容易产生锁等待、死锁和处理失败对数据库的影响较大。所以分布式锁的应用成为大多数的首选。
Zookeeper实现分布式锁是通过节点和临时顺序节点来实现的：
1. 在构造函数里面启动的时候建立一个节点，假如命名为：lock。节点类型为持久节点（PERSISTENT）【ZooKeeper里面的znode节点会自动同步的，而且是强一致性，创建一个节点后只有ZooKeeper集群同步完成后算成功】
2. 每当进程需要访问共享资源时，会在lock节点下面建立响应的顺序子节点，节点类型为临时顺序节点（EPHEMERAL_SEQUENTIAL）
3. 在建立子节点之后，判断刚刚建立的子节点顺序号是否为最小节点，如果是最小节点，则可以获得该锁对资源进行访问。（临时子节点建立会自动生成一个序号的）
4. 如果不是该节点，就获得该节点的上一顺序节点，并给该节点是否存在注册监听事件。同时在这里阻塞。等待监听事件的发生。获得控制权（实现watch接口，并且重写process方法，在process里面实现监听）
5. 当完成之后，关闭ZooKeeper连接，进而可以应发监听事件，释放该锁（客户端关闭ZooKeeper连接之后会删除当前的临时节点）
锁类型：
-
共享锁: 全局同步分布式锁, 同一时间两台机器只有一台能获得同一把锁.
-
共享读写锁: 用于分布式的读写互斥处理, 同时生成两个锁:一个读锁, 一个写锁, 读锁能被多个应用持有, 而写锁只能一个独占, 当写锁未被持有时, 多个读锁持有者可以同时进行读操作
-
共享信号量: 在分布式系统中的各个JVM使用同一个zk lock path, 该path将跟一个给定数量的租约(lease)相关联, 然后各个应用根据请求顺序获得对应的lease, 相对来说, 这是最公平的锁服务使用方式.
-
多共享锁:内部构件多个共享锁(会跟一个znode path关联), 在acquire()过程中, 执行所有共享锁的acquire()方法, 如果中间出现一个失败, 则将释放所有已require的共享锁; 执行release()方法时, 则执行内部多个共享锁的release方法(如果出现失败将忽略)
客户端向zk服务器注册watcher的同时，会将watcher对象存储在客户端的watchManager，Zk服务器触发watcher事件后，会向客户端发送通知，客户端线程从watchManager中݊调起watcher执行
一个复杂的任务，近需要从分布式机器中选出一台机器来执行。诸如此类的问题，我们统称为“Leader选举”。Leader选举是保证分布式数据一致性的关键所在。
Curator提供了两种选举方案：Leader Latch和Leader Election
Leader Latch ： 随机从候选着中选出一台作为leader，选中之后除非调用close()释放leadship，否则其他的后选择无法成为leader
Leader Election ： 通过LeaderSelectorListener可以对领导权进行控制， 在适当的时候释放领导权，这样每个节点都有可能获得领导权。 而LeaderLatch则一直持有leadership， 除非调用close方法，否则它不会释放领导权。
不过在测试过程中，貌似达到的效果都差不多，不知道是不是哪里理解错了