2018-12-08 补充:
其实这两种方案也就是Curator提供的两种选主机制:
基于选举和基于抢占的选主方式，具体原理和使用参见以下链接
[Curator] Leader Latch 的使用与分析
[Curator] Leader Election 的使用与分析
建议直接使用Curator封装好的接口
分布式锁种类
zookeep分布式锁的种类：排他锁、共享锁
如何用 zookeeper 实现分布式锁 - world6 的博客 - CSDN 博客
锁实现
Curator已经实现的分布式锁：
可重入锁：InterProcessMutex 实现了可重入的排它锁，支持锁等待超时、保证获取锁的公平性。
不可重入锁：InterProcessSemaphoreMutex 实现了不可重入的排它锁，支持锁等待超时、保证获取锁的公平性。可以在多个线程间传递和释放锁，从而满足异步调用场景下的锁需求。
信号量：InterProcessSemaphoreV2 实现了信号量，支持信号量等待超时、保证获取信号量的公平性。客户端每次获取信号量成功都会返回一个租约（Lease）对象，建议客户端在 finally 代码块 close 这个租约对象以释放租约。注意在线程重入时，每次获取信号量成功也会占用一个租约。另外，在多进程场景下，可以通过 SharedCountReader 来保障最大租约数的一致性，避免不同的进程设置不同的最大租约数。
读写锁：InterProcessReadWriteLock 实现了可重入读写锁，支持锁等待超时、保证获取锁的公平性。并且支持写锁降级（持有写锁的线程可以同时获取到读锁），不支持读锁升级（持有读锁的线程不能同时获取到写锁）。 联锁：InterProcessMultiLock 实现了联锁，它使用装饰器模式实现多把锁的组合，与可重入锁、不可重入锁实现相同的接口，使得可以像使用单锁一样使用联锁。联锁获取成功代表它拥有的所有内部锁都获取成功，联锁获取失败则会自动释放所有内部已经获取成功的部分锁，从而保证联锁的原子性语义。
教你使用 Zookeeper 实现分布式锁(上)
实际应用
需求：集群中所有host都有池化好的相同资源，后台取资源比较耗时，而且会频繁请求这个集群来取。
基于排他锁设计
开始：各host在zk上竞争创建临时节点，创建成功者为主节点，同时其他候选host监听节点目录。后台取目录下的节点信息，从主节点中获取资源。当主服务主动删除节点或者会话失效时，候选host将继续竞争选主。
主节点结束： 当主节点被后台占用最后一个资源时，主动删除临时节点。
重新选主： 候选host发现节点目录有节点删除事件，如果自己有空余资源，立刻参与选主，否则继续监听节点目录。
所有节点忙： 当所有host没有空余资源时，zk目录下没有节点。
有空余节点： 当有host重新拥有资源，检查节点目录是否有节点，如果没有节点，则尝试创建，创建成功则成为主服务，否则继续监听节点目录。
基于共享锁设计
开始：各host在zk上竞争创建临时有序节点，后台从创建最小节点的host中获取资源，因此该host成为主节点。
主节点结束： 当主节点被后台占用最后一个资源时，主动删除临时节点。当自己重新拥有资源后，再次在zk创建临时有序节点，参加排队。
重新选主：后台从之前次小的节点host中获取资源，该host成为主节点。
所有节点忙：当所有host没有空余资源时，zk目录下没有节点。
有空余节点： 当有host重新拥有资源，再次在zk创建临时有序节点，立即成为主节点。
