大数据学习笔记-------------------(8)

大数据学习笔记-------------------(8)

第7章 zookeeper基本组成与工作流程

7.1 zookeeper 架构

看看下面的图表。它描绘的ZooKeeper的“客户端- 服务器架构”：

zookeeper架构中一部分组件在下表中说明。

7.2分层命名空间

下图描述了内存中表示ZooKeeper的文件系统的树形结构。ZooKeeper的节点被称为znode。每个znode由一个名称标识和路径（/）的序列隔开。

Ø  在图中，首先必须通过“/”分隔根znode。在根节点下，有两个逻辑命名空间：config、workers。

Ø  在config命名空间用于集中配置管理和workers命名空间用于命名。

Ø  在config命名空间下，每个znode可以存储高达1MB的数据。这类似于UNIX文件系统，不同的是父znode可以存储数据。这种结构的主要目的是存储同步数据以及描述znode的元数据。这种结构被称为ZooKeeper Data Model。

ZooKeeper数据模型中的每个znode维持一个 stat结构。一个stat结构仅仅提供一个znode的元数据。它包括:版本号(Versionnumber)、动作控制列表(Action control list,ACL)、时间戳(Timestamp)、数据长度(Data length)。

Ø  版本号：每znode具有版本号，这意味着每次与znode改变相关的数据，其相应的版本号也将增加。当多个zookeeper的客户端尝试在同一znode执行操作时，使用版本号是重要的。

Ø  动作控制列表（ACL）：ACL基本上是用于访问znode的认证机制。它管理所有节点读和写操作。

Ø  时间戳：时间戳表示znode创建和修改经过的时间。它通常以毫秒为单位表示。ZooKeeper用“Transaction ID”（zxid）标识znodes的每次改变。Zxid是唯一的，维持每Transaction时间，这样就可以轻松地识别从一个请求到另一个请求经过的时间。

Ø  数据长度：存储在znode的数据总量是数据的长度。最多可以存储1MB的数据。

7.2.1Znode类型

Znode类型有三种分别是：持久性、连续和短暂。

Ø  持久znode：持久性znode一旦被创建就会一直存在，即使客户端断开连接。默认情况下，所有znodes都是持久类型除非被指定。

Ø  短暂znode：当客服端是alive时，短暂znode处与活动状态。当一个客户端从zookeeper ensemble断开连接，那么短暂znodes自动删除。由于这个原因，只有短暂znodes不允许有子节点。如果一个短暂znode被删除，那么下一个合适的节点将填补其位置。短暂znodes在leader election中起重要作用。

Ø  连续znode：连续znodes可以是持久或短暂的。当一个新的znode为连续znode，则zookeeper通过附加一个10位序列号作为原始名称设置znode的路径。例如，如果路径/ MyApp一个znode是为连续znode，zookeeper将路径改变到/ myapp0000000001并设置下一个序列号为0000000002.如果两个顺序znodes被同时创建，然后zookeeper从不为每个znode使用相同数字。顺序znodes在锁和同步中起重要作用。

7.3 会话(Sessions)

Sessions对于zookeeper的操作非常重要。在会话中请求按照FIFO顺序执行。一旦客户机连接到服务器，则会话将建立一个会话ID被分配给客户端。

客户在特定的时间间隔发送心跳保持会话有效。如果合奏的ZooKeeper不从客户端接收心跳比在服务的开始规定的期限（会话超时）越多，它决定了客户端死亡。

会话超时通常以毫秒为单位表示。当一个会话因任何原因终止，该会话还期间创建的临时znodes被删除。

7.4 监视Watches)

监视是为客服端获取有关ZooKeeperensemble变化信息的一种简单机制。客户端可以同时读取特定znode通过设置监视。监视发送关于任何znode（在其客户端寄存器）的变化信息到登记的客户端。

与Znode关联的数据被修改或Znode的子节点被改变会引起znode改变。监视只能触发一次。如果客户希望再次通知，它必须通过另一次读操作来完成。当连接会话已过期，客户端会从服务器断开，并在相关的监视也将被删除。

7.5 工作流程

一旦ZooKeeperensemble启动时，它会等待客户端连接。客户端将连接到ZooKeeper ensemble的一个节点。它可能成为leader或follower节点。一旦客户机连接成功，该节点的会话ID分配给特定的客户端，并发送一个确认信息到客户端。如果客户端没有得到确认，它将尝试连接ZooKeeper ensemble中的另一个节点。一旦连接到一个节点，在有规律的间隔内，客户端将发信息跳到节点以确保连接不会丢失。

如果客户想要读一个特定znode，它发送一个读请求给znode路径的节点和节点返回从其自己的数据库中获取所请求的znode。出于这个原因，ZooKeeper ensemble读是很快的。

如果客户端希望将数据存储在ZooKeeperensemble中，它发送znode路径和数据到服务器。连接的服务器将请求转发到leader，然后leader将重新发出书面请求给所有的follower。如果只有一个节点的成功响应，这时表明写请求成功，与此同时成功的状态码将被发送到客户端。否则，该写请求将失败。严格来说大部分的点被称为法定人数（Quorum）。

分析ZooKeeperensemble中节点数目不同所产生的影响：

Ø  如果只有一个节点，那么ZooKeeperensemble成功与失败取决于该节点的成功与失败。它有助于“单点故障”，它不在生产环境中推荐的。

Ø  如果有两个节点，一个节点发生故障，还有一个节点。

Ø  如果有三个节点和一个节点发生故障，还有其他节点，因此，它是最低要求。ZooKeeper ensemble在实际生产环境至少有三个节点。

Ø  如果有四个节点和两个节点失败，再次失败，它类似于具有三个节点。额外的节点没有任何作用，因此，最好添加奇数节点，例如，3，5，7。

众所周知，在ZooKeeperensemble中的一个写操作比读操作昂贵，因为所有的节点需要写入相同的数据的它们的数据库。因此，更少的节点最好（3，5或7）大于用于平衡环境的节点数目。

上图描述了ZooKeeper的工作流程和下表对不同的组件说明：

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。