[toc]
Q: 如果同时希望加锁的客户端非常多，有一千多个，同时监听一个节点取锁的话会有什么问题#
A:
会发生羊群效应。
即节点被删除释放锁时， 需要借助watch机制通知所有客户端， 消耗大量资源
- 如果有1000个客户端watch 一个znode的exists调用，当这个节点被创建的时候，将会有1000个通知被发送。这种由于一个被watch的znode变化，导致大量的通知需要被发送，将会导致在这个通知期间的其他操作提交的延迟
Q: 那么如何避免监听过多？#
A:
znode不止一个， 但是会存在链式关系的锁，有点像是公平排队锁，先到先得。
lock之间会按顺序做监听， 而其他的客户端则单独监听自己需要的那个lock即可。
比如我们按照上述逻辑创建了有三个znodes.
/lock/lock-001,/lock/lock-002,/lock/lock-003.
/lock/lock-001 的这个客户端获得了lock
/lock/lock-002 的客户端watch /lock/lock-001
/lock/lock-003 的客户端watch /lock/lock-002
通过这种方式，每个节点只watch 一个变化
-
核心逻辑：不需要关心所有的事件，判断自己是否是所有节点中序号最小的。于是，很容易可以联想的到的是，每个节点的创建者只需要关注比自己序号小的那个节点。
