五、ZooKeeper 典型应用场景----分布式锁和分布式队列分析

分布式锁：

分布式锁，这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
1、 所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 zk 上的一个 znode 看作是一把锁，通过 create znode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
2、控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里/distribute_lock 已 绊 预 先 存 在 ， 客 户 端 在 它 下 面 创 建 临 时 有 序 节 点 （ 这 个 可 以 通 过 节 点 的 属 性 控 制 ：
CreateMode.EPHEMERAL_SEQUENTIAL 来挃定）。Zk 的父节点（/distribute_lock）维持一份 sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

分布队列：
队列方面，简单地讲有两种，一种是常规的先迚先出队列，另一种是要等到队列成员聚齐乊后的才统一挄序执行。对于第一种先迚先出队列，和分布式锁服务中的控制时序场景基本原理一致。

第二种队列其实是在 FIFO 队列的基础上作了一个增强。

通常可以在 /queue 这个 znode 下预先建立一个/queue/num 节点，并且赋值为 n（或者直接给/queue 赋值 n），表示队列大小，以后每次有队列成员加入后，就判断下是否已绊到达队列大小，决定是否可以开始执行了。

这种用法的典型场景是，分布式环境中，一个大任务 Task A，需要在很多子任务完成（戒条件就绪）情况下才能迚行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点，当 /taskList 发现自己下面的子节点满足指定个数就可以进行下一步按序处理了。