ZooKeeper实现排他锁
排他锁又称为写锁或独占锁，是一种基本的锁类型。如果事务T1对数据O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事物都不能再对这个数据对象进行任何类型的操作—直到T1释放了排他锁。
1. 定义锁
ZK通过一个数据节点来表示一个锁，例如：/exclusive_lock/lock节点就可以被定义为一个锁：
2. 获取锁
在需要获取排他锁时，所有的客户端都会试图通过调用create()接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。ZK会保证在所有的客户端中，最终只有一个客户端能够创建成功，那么就可以认为该客户端获取了锁。同时，所有没有获取到锁的客户端就需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lcok节点的变更情况。
3. 释放锁
在“定义锁”部分，我们已经提到，/exclusive_lock/lock是一个临时节点，因此在以下两种情况下，都有可能释放锁。
- 当前获取锁的客户端机器发生宕机，那么ZK上的临时节点就会被移除。
-
正常执行完业务逻辑之后，客户端就会主动将自己创建的临时节点删除。
无论在什么情况下移除了lock节点，ZK都会通知所有在/exclusive_lock节点上注册了子节点变更Watcher监听的客户端。这些客户端在接收到通知后，再次重新发起分布式锁获取，即重复“获取锁”过程。整个排他锁的获取和释放流程如下图所示
排他锁的获取和释放流程.png
ZooKeeper实现共享锁
共享锁又称为读锁，同样是一种基本的锁类型。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁—直到该数据对象上的所有锁都被释放。
共享锁和排他锁最根本的区别在于，加上排他锁后，数据对象只对一个事务可见，而加上共享锁后，数据对所有事务都可见。
1. 定义锁
和排他锁一样，同样是通过ZK上的数据节点来表示一个锁，是一个类似于“/shared_lock/[Hostname]-请求类型-序号”的临时顺序节点，例如/shared_lock/192.168.0.1-R-000000001，那么，这个节点就代表了一个共享锁
2. 获取锁
在需要获取共享锁时，所有客户端都会到/shared_lock这个节点下面创建一个临时顺序节点，如果当前是读请求，那么就创建例如/shared_lock/192.168.0.1-R-000000001的节点；如果是写请求，那么就创建例如/shared_lock/192.168.0.1-W-000000001的节点。
3. 判断读写顺序
根据共享锁的定义，不同的事务都可以同时对同一个数据对象进行读取操作，而更新操作必须在当前没有任何事务进行读写操作的情况下进行。基于这个原则，我么来看看如何通过ZK的节点来确定分布式读写顺序：
- 创建完节点后，获取/shared_lock节点下的所有子节点，并对该节点注册子节点变更的通知。
- 确定自己的节点序号在所有子节点中的顺序。
- 对于读请求：
如果没有比自己序号小的子节点，或是所有比自己序号小的子节点都是读请求，那么表明自己已经是成功获取到了共享锁，同时开始执行读取逻辑。
如果比自己序号小的子节点中有写请求，那么就需要进入等待。
对于写请求：
如果自己不是序号最小的子节点，那么就需要继续进入等待。
4. 释放锁
释放锁的逻辑和排他锁是一致的，这里不再赘述。整个共享锁的获取和释放流程如下图所示：
避免羊群效应—改进版的分布式锁
对于上面的共享锁，当某个客户端在移除自己的共享锁之后，ZK发送子节点Watcher通知给所有机器，然而这个通知除了给第二个顺序子节点产生实际影响外，对于余下的其它所有机器都没有任何作用，还是需要陷入等待。一旦集群规模变大，每一台机器都要在收到Watcher变更通知后进行读写顺序判断，大量的通知会造成ZooKeeper性能下降。所以需要对分布式锁进行改进，在注册节点时，只需要对比其小的那个节点注册监听，最小节点完成任务释放锁，只会给发出通知给比它大的那个节点，这样一来，就避免了变更的节点发出大量的通知，所以分布式锁的改进思路就是尽量缩小锁的范围。
在实际开发工程中，提倡根据具体的业务场景和集群规模来选择适合自己的分布式锁实现：在集群规模不大、网络资源丰富的情况下，第一种分布式锁实现方式时简单实用的选择；而如果集群规模达到一定程度，并且希望能够精细化地控制分布式锁机制，那么不妨试试改进版的分布式锁实现。
