Zookeeper 简明教程

Zookeeper - Workflow

当 ZooKeeper 协同程序启动后，会等待客户端连接。客户端将连接到 ZooKeeper 协同程序中的一个节点。可以是领导者节点或追随者节点。一旦客户端连接，节点会为特定客户端分配会话 ID，并向客户端发送确认。如果客户端没有收到确认，它会尝试连接 ZooKeeper 协同程序中的另一个节点。连接到一个节点后，客户端会定期向该节点发送心跳，以确保连接不会丢失。

  1. If a client wants to read a particular znode, 它会向带有 z 节点路径的节点发送 read request ，而该节点会通过从自己的数据库中获取所需的 z 节点返回它。因此，读取操作在 ZooKeeper 协同程序中的速度很快。

  2. If a client wants to store data in the ZooKeeper ensemble ，它会向服务器发送 z 节点路径和数据。已连接的服务器会将请求转发给领导者，然后领导者会向所有追随者重新发出写入请求。如果只有大多数节点成功响应，则写入请求将成功并且会向客户端发送成功返回码。否则，写入请求将失败。大多数节点会称为 Quorum 。

Nodes in a ZooKeeper Ensemble

让我们分析同时在 ZooKeeper 协同程序中拥有不同数量的节点的影响。

  1. 如果我们有 a single node ，则当那个节点失败时，ZooKeeper 协同程序会失败。它会促成“单点故障”并且不推荐在生产环境中使用。

  2. 如果我们有 two nodes 并且一个节点失败，我们也没有大多数节点，因为二分之一不是大多数。

  3. 如果我们有 three nodes 并且一个节点失败，我们有大多数节点，因此，它是最低要求。ZooKeeper 协同程序必须在实时生产环境中至少有三个节点。

  4. 如果我们有 four nodes 并且两个节点失败，则会再次失败，这就像拥有三个节点一样。额外的节点没有任何用处，因此，最好以奇数添加节点，例如 3、5、7。

我们知道一个写入进程在 ZooKeeper 协同程序中的开销要大于一个读取进程，因为所有的节点都需要在其数据库中写入相同的数据。因此，为了实现一个均衡的环境，拥有较少数量的节点（3、5 或 7）要优于拥有大量节点。

下图描绘了 ZooKeeper 工作流，而随后的表格解释了其不同的组件。

zookeeper ensemble

Component

Description

Write

写入进程由领导者节点处理。领导者将写入请求转发给所有 z 节点并等待 z 节点的答复。如果一半的 z 节点回复，则写入进程完成。

Read

读取操作由一个特定的已连接 z 节点在内部执行，因此无需与集群交互。

Replicated Database

该操作用于在 zookeeper 中存储数据。每个 z 节点都有自己的数据库，在帮助下，每个 z 节点在同一时间都有相同的数据。一致性

Leader

领导者是负责处理写入请求的 z 节点。

Follower

追随者从客户端接收写入请求，并将它们转发给领导者 z 节点。

Request Processor

仅存在于领导者节点中。它控制来自追随者节点的写入请求。

Atomic broadcasts

负责将领导者节点的更改广播给追随者节点。