ZooKeeper 的羊群效应

一个需要避免的问题是当一个特定的znode 改变的时候ZooKeper 触发了所有watches 的事件。

举个例子，如果有1000个客户端watch 一个znode的exists调用，当这个节点被创建的时候，将会有1000个通知被发送。这种由于一个被watch的znode变化，导致大量的通知需要被发送，将会导致在这个通知期间的其他操作提交的延迟。因此，只要可能，我们都强烈建议不要这么使用watch。仅仅有很少的客户端同时去watch一个znode比较好，理想的情况是只有1个。

举个例子，有n 个clients 需要去拿到一个全局的lock.一种简单的实现就是所有的client 去create 一个/lock znode.如果znode 已经存在，只是简单的watch 该znode 被删除。当该znode 被删除的时候，client收到通知并试图create /lock。这种策略下，就会存在上文所说的问题，每次变化都会通知所有的客户端。

另外一种策略就是每个client去创建一个顺序的znode /lock/lock-.ZooKeeper 会自动添加顺序号/lock/lock-xxx.我们可以通过/lock getChildren 去拿到最小的顺序号。如果client不是最小的序列号，就再比自己小一点的znode上添加watch.

比如我们按照上述逻辑创建了有三个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 一个变化。