在深入了解ZooKeeper的工作之前，让我们先看一下ZooKeeper的基本概念.我们将在本章讨论以下主题 :
架构
分层命名空间
会话
手表
看一下下图.它描绘了ZooKeeper的"客户端 - 服务器架构".
下表中解释了作为ZooKeeper架构一部分的每个组件.
| 部分 | 描述 |
|---|---|
| 客户端 | 客户端是我们分布式应用程序集群中的一个节点，它从服务器访问信息.对于特定的时间间隔，每个客户端都会向服务器发送一条消息，让服务器知道客户端是否处于活动状态. 同样，服务器在客户端连接时发送确认.如果连接的服务器没有响应，客户端会自动将消息重定向到另一台服务器. |
| 服务器 | 服务器是ZooKeeper集合中的一个节点，它为客户端提供所有服务.给客户确认通知服务器还活着. |
| Ensemble | ZooKeeper服务器组.形成整体所需的最小节点数为3. |
| Leader | 服务器节点，如果任何连接的节点发生故障，它将执行自动恢复.领导者在服务启动时当选. |
| 追随者 | 跟随领导者的服务器节点指令. |
下图描绘了树的结构ZooKeeper文件系统用于内存表示. ZooKeeper节点称为 znode .每个znode都由一个名称标识，并以路径序列(/)分隔.
在图中，首先你将 znode 的根分隔为"/".在root下，您有两个逻辑命名空间 config 和 worker .
config namespace用于集中配置管理， workers 命名空间用于命名.
在 config
ZooKeeper数据模型中的每个znode都维护 stat 结构.统计信息只提供znode的元数据.它由版本号，动作控制列表(ACL)，时间戳和数据长度组成.
版本号 : 每个znode都有一个版本号，这意味着每次与znode关联的数据发生更改时，其对应的版本号也会增加.当多个zookeeper客户端尝试在同一个znode上执行操作时，使用版本号很重要.
操作控制列表(ACL) : ACL基本上是用于访问znode的身份验证机制.它管理所有znode读写操作.
时间戳 : 时间戳表示从znode创建和修改起经过的时间.它通常以毫秒表示. ZooKeeper从"Transaction ID"(zxid)中识别对znode的每个更改. Zxid 是唯一的，可以为每笔交易保留时间，以便您轻松识别从一个请求到另一个请求所经过的时间.
数据长度 : 存储在znode中的数据总量是数据长度.您最多可以存储1MB的数据.
Znodes被分类作为持久性，顺序性和短暂性.
持久性znode : 即使在创建该特定znode的客户端断开连接后，持久性znode仍然存在.默认情况下，除非另有说明，否则所有znode都是持久的.
Ephemeral znode : 临时znode处于活动状态，直到客户端处于活动状态.当客户端与ZooKeeper集合断开连接时，短暂的znode会自动删除.出于这个原因，只允许短暂的znodes进一步生育孩子.如果删除了短暂的znode，则下一个合适的节点将填充其位置.短暂的znodes在领导者选举中发挥着重要作用.
顺序znode : 顺序znode可以是持久的也可以是短暂的.当新的znode被创建为顺序znode时，ZooKeeper通过将10位序列号附加到原始名称来设置znode的路径.例如，如果将路径为/myapp 的znode创建为顺序znode，则ZooKeeper会将路径更改为/myapp0000000001 并将下一个序列号设置为0000000002.如果为2顺序znode是同时创建的，然后ZooKeeper永远不会为每个znode使用相同的数字.顺序znode在锁定和同步中起着重要作用.
会话非常重要用于ZooKeeper的操作.会话中的请求以FIFO顺序执行.一旦客户端连接到服务器，将建立会话并将会话ID 分配给客户端.
客户端发送心跳在特定时间间隔保持会话有效.如果ZooKeeper集合没有从客户端接收心跳超过服务启动时指定的时间段(会话超时)，则它会判定客户端已经死亡.
会话超时通常是用毫秒表示.当会话因任何原因而结束时，在该会话期间创建的短暂znode也会被删除.
手表是客户端的简单机制获取有关ZooKeeper集合中的更改的通知.客户端可以在读取特定znode时设置监视.手表向注册客户端发送任何znode(客户端注册)更改的通知.
Znode更改是修改与znode相关的数据或更改znode的子项.手表仅触发一次.如果客户端再次想要通知，则必须通过另一个读取操作完成.当连接会话到期时，客户端将与服务器断开连接，并且相关的监视也将被删除.
