版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u012831423/article/details/82766058
Zookeeper基础
很多用于协作的原语常常在很多应用之间共享，因此，设计一个用于协作需求的服务的方法往往是提供原语列表，暴露出每个原语的实例化调用方法，并直接控制这些实例。比如我们可以说分布式锁机制组成了一个重要的原语，同时暴露出创建（create）获取(acquire) 和释放(release)三个调用方法，这种设计存在一个缺陷，要么提供一份详细的原语列表，要么提供API的扩展，以便引入新的原语。其次，这种方式实现原语的服务使得应用丧失了灵活性。
因此，ZK另辟蹊径，不直接暴露原语，取而代之，暴露由一小部分调用方法组成的类似文件系统的API，以便允许应用实现自己的原语，通常使用菜谱（recipes）来表示这些原语的实现。菜谱包括ZK操作和维护一个小型的数据节点，这些节点被称为znode。下图描述了一个znode树结构，跟节点包含4个子节点，其中3个子节点拥有下一级节点，叶子节点存储了数据
/workers节点作为父节点，其下每个znode子节点保存了系统中一个可用从节点信息，如图，有一个从节点foot.com:2181
/tasks节点作为父节点，其下每个znode子节点保存了所有已经创建并等待从节点执行的任务的信息，主-从模式的应用的客户端在/tasks下每添加一个znode子节点，用来表示一个新任务，并等待任务状态的znode节点
/assign节点作为父节点，其下每个znode子节点保存了分配到某个从节点的一个任务信息，当主节点为某个从节点分配了一个任务，就会在/assign下增加一个子节点
针对一个znode ，没有数据常常表达了重要的信息，比如在主-从模式中，主节点的znode没有数据，表示当前还没有选举出主节点。