Zookeeper 基础 -- 中国DBA社区

ZooKeeper 有如下的基本概念：

下图描绘了ZooKeeper 的“客户端 - 服务器架构”。

部分	描述
Client	客户端，分布式应用集群中的一个节点，从服务器获取信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活着的。类似地，当客户端连接时，服务器发送确认。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。
Server	服务器， ZooKeeper集合中的一个节点，为客户端提供所有的服务。向客户端发送确认，通知服务器处于活动状态。
合组	ZooKeeper 服务器组。形成整体所需的最小节点数为3。
Leader	服务器节点，如果任何连接的节点发生故障，则执行自动恢复。领导者在服务启动时被选举。
Follower	服务器节点跟随引导指令。

下图显示了用于内存中表示 ZooKeeper 文件系统的树形结构。 ZooKeeper节点被称为znode。每个znode由一个名称识别，并通过路径（/）序列隔开。

在图中，首先有一个根znode，它由“/”分隔。在根下，有两个逻辑命名空间 config 和 workers。
在config命名空间用于集中配置管理以及 workers 命名空间用于命名。
在config命名空间下，每个znode可以存储高达 1MB 的数据。这类似于UNIX文件系统，不同的是父 znode 也可以存储数据。这种结构的主要目的是存储同步数据以及描述znode的元数据。这种结构被称为 ZooKeeper数据模型。

在 ZooKeeper 数据模型中每个 znode 维护一个 stat 结构。一个stat只提供一个 znode 元数据。它由版本号，动作控制列表（ACL），时间戳和数据长度组成。

版本号
每个znode都有版本号，这意味着每次与znode关联的数据发生更改时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用很重要。
操作控制列表(ACL)
ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。
时间戳
时间戳表示创建和修改znode所经过的时间。它通常表示为毫秒。 ZooKeeper标识“事务ID”(zxid)对znode的每个更改。Zxid 是唯一的，并且为每个事务维护时间，以便您可以轻松地确定从一个请求到另一个请求的时间。
数据长度
存储在znode中的数据总量是数据长度。最多可以存储1MB的数据。

Persistence znode
即使在创建该特定znode的客户端断开连接后，Persistence znode仍然存在。默认情况下，除非另有说明，否则所有znode都是持久的。
临时znode
临时znode有效，直到客户端活着。当客户端从ZooKeeper集合断开连接时，临时znode会自动删除。为此，只有临时znode不允许子节点。如果删除临时znode，则下一个合适的节点将填充其位置。临时znode在领导选举中发挥重要作用。
顺序znode
顺序znode可以是持久的或短暂的。当一个新的znode被创建为一个连续的znode，然后ZooKeeper设置znode的路径，通过附加一个10位的序列号到原始名称。
例如，如果将具有路径 / myapp 的znode创建为顺序znode，则ZooKeeper将将路径更改为/ myapp0000000001 ，并将下一个序列号设置为0000000002.如果两个顺序znode是并发创建的，那么ZooKeeper从不对每个znode使用相同的数字。顺序znode在锁定和同步中起重要作用。

会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。
客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合没有从客户端接收到超过在服务启动时指定的时间段(会话超时)的心跳，则它决定客户端死亡。

会话超时通常用毫秒表示。当会话由于任何原因结束时，在该会话期间创建的临时znode也会被删除。

监视是一种简单的机制，使客户端得到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置监视。监视会向注册的客户端发送任何znode(客户端注册表)更改的通知。

Znode更改是与znode的相关数据的修改或znode子节点的更改。监视只被触发一次。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关联的监视也将被删除。

签到成功