在讲分布式锁之前，我们先看看zookeeper的基础特性，zookeeper主要是一个文件系统数据结构，节点可以分为以下几类
一、节点类型
1.PERSISTENT-持久化目录节点
当客户端与zookeeper断开连接后，该节点依然存在，只要不进行手动删除，他将会永久存在
2.PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
和持久化目录节点类似，但是会给该节点名称进行顺序编号
3.EPHEMERAL-临时目录节点
当客户端与zookeeper断开连接后，该节点会被删除
4.EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
和临时目录节点类似，但是会给该节点名称进行顺序编号
5.Container 节点（3.5.3 版本新增）
当只建立一个Container节点，和建立一个持久化目录节点是一样的，但是当Container节点，有子节点时，子节点被删除完后，该Container节点会被zookeeper自动清除，时间间隔60s；
6.TTL 节点
和redis过期缓存有点类似，默认禁用，现在该功能不太稳定
创建节点命令
create [-s] [-e] [-c] [-t ttl] path [data] [acl]
s:顺序节点
e:临时节点
c:容器节点
t:可以给节点添加过期时间，默认关闭
二、监听机制
客户端可以监听自己关系的节点，或者目录节点，或者目录下的所有子节点
当客户端监听的对象发生删除或者修改（有子节点被创建，或被删除）时，会触发相应的事件通知到客户端
get -w /path
针对节点监听；当节点触发修改事件时，会通知到监听的客户端；一旦事件触发，则监听会被移除，需要根据相应的业务来判断，是否需要继续监听；
ls -w /path
对目录进行监听，当该目录下有子节点的创建，以及删除，则会触发；监听也是一次性的；
ls -R -w /path
对目录进行递归监听，每个目录下的监听也是一次性的
三、分布式锁
了解了上面两个特性，我们来看下zookeeper分布式锁是怎么实现的；我们现在一般用的zookeeper客户端是Curator，这个里面有公平锁，非公平锁，读写锁等
1.非公平锁
创建PERSISTENT（临时目录节点），创建成功则加锁成功，其他应用创建则会失败，然后注册一个当前节点的监听，挂起线程；当获取锁的应用释放锁时（自己释放或者当前机器挂掉），删除该临时目录节点，则其他监听的应用则会被唤醒，再次尝试获取锁，获取成功的继续执行，未获取到锁的应用，则继续监听，然后挂起；
2.公平锁
非公平锁有个弊端，就是羊群效应，当节点被删除时，所有应用都会被唤醒争抢锁，会加大服务器的压力；公平锁，在某个目录下创建EPHEMERAL_SEQUENTIAL（临时顺序编号目录节点），当创建完成后，获取当前目录下所以节点，判断自己节点是否是最小节点，如果是最小节点，则获取到锁，继续执行；如果不是最小节点，则监听上一个节点，当上一个节点被释放时，再次判断是否是最小节点；如果是，则继续执行；如下图
3.读写锁
当应用存在读多写少的场景，则公平锁也不适用，并发量不高，则需要读写锁；读写锁，在锁目录下创建EPHEMERAL_SEQUENTIAL（临时顺序编号目录节点），创建的节点都有标识，是读锁，还是写锁；当读锁创建成功后，会获取到当前所有节点，如果是最小节点或者比当前节点更小的都是读节点，则继续执行，如果比当前节点小的节点中有写节点，则监听该写节点，挂起当前线程，当写节点锁被释放时，当前线程被唤醒，获取所有节点，再次判断；当写锁创建成功时，判断逻辑和公平锁一样，只要不是最小节点，则监听上一个节点，挂起当前线程；如下图：
三、zookeeper锁避免的问题
加锁成功时，出现网络波动，客户端立马连接上时，导致客户端应用不知道是否加锁成功；所以在每次加锁时，会加一个当前应用生成类型与uuid的前缀，当应用不知道是否加锁成功时，获取到所以节点，判断是否有该前缀的节点，则知道是否加锁成功，如果加锁失败，则重新加锁；
