zookeeper 的应用

不建议使用（单独）zookeeper 做分布式队列，有几点原因，以下原因摘抄于curator的官网：

1、zookeeper有1MB的传输限制。而在队列中，拥有很多的数据节点，通常包括数千个，如果有较多的很大的znode，将会降低zookeeper的启动速度。需要自己显式地注明initLimit和syncLimit。

2、znode太大，会导致清理起来很困难，并且getchildren()失效

3、如果zookeeper上有数千个znode 或者子级别的znode，zookeeper的效率将会明显下降

4、zookeeper的数据都是保存在内存中的，无论采取何种方法，包括但不限于使用API ，也只能得到对应的内存信息，其他相关信息都不会得到

下面是应用场景，还需要自测试例子：

1、锁

1.1 共享可重用锁：全局同步的完全分布式锁，这意味着在任何快照中，没有两个客户机认为它们持有相同的锁。也就是说，这个锁可以被重用。

1.2 共享锁：类似于共享可重复锁，但是不是可以重用的。

1.3 共享可重用读写锁：跨jvm工作的可重入读写互斥锁。读写锁维护一对关联锁，一个用于只读操作，一个用于写入。只要没有写入器，读锁可以由多个读取器进程同时持有。写锁是排他的。  ----这个有点叼

1.4 共享信号量——在jvm之间工作的计数信号量。所有使用相同锁路径的jvm中的所有进程都将获得一组进程间有限的契约。此外，这个信号量基本上是“公平的”——每个用户将按照请求的顺序获得一个租约(从ZK的观点来看)。-----这是几个意思？

1.5 多重共享锁：将多重共享锁放在一个实体里面。当调用acquire()的时候，将会获得所有的锁。当调用release()的时候，将会释放所有的锁。

2、Barrier

2.1 Barrier：分布式系统使用障碍来阻止一组节点的处理，直到满足了允许所有节点继续进行的条件。

2.2 Double Barrire：允许客户端同步计算的开始和结束。当足够多的进程加入Barrier时，进程开始计算并在完成Barrier后离开Barrier。

3、计数器

3.1 共享计数器-管理一个共享整数。所有观察同一路径的客户机都将具有共享整数的最新值(考虑到ZK的正常一致性保证)。

3.2 分布式原子长：一个尝试原子增量的计数器。它首先尝试使用乐观锁定。如果失败，将使用一个可选的InterProcessMutex。对于乐观和互斥锁，都使用重试策略来重试增量。