CNDBA社区
1 Zookeeper 工作流
当ZooKeeper集合启动时，它会等待客户端连接。客户端将连接到ZooKeeper的集合的其中一个节点。它可能是一个领导者或跟随者节点。当客户机连接时，该节点分配会话ID给特定的客户端，并发送一个确认消息给客户端。如果客户端没有得到确认，它会尝试连接ZooKeeper集合的另一个节点。当连接到一个节点后，客户端将以规则的间隔发送心跳到节点，以确保连接不会丢失。
- 如果客户端想要读取特定的znode，会向具有znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取它来返回所请求的znode 。 为此，在ZooKeeper集合中读取速度快。
- 如果客户端想要将数据存储在ZooKeeper集合中，它会将znode路径和数据发送到服务器。 连接的服务器将该请求转发给领导者，然后领导者将向所有的跟随者重新发出写入请求。 如果只有大多数节点成功响应，则写请求将成功，并且成功的返回码将被发送到客户端。否则，写入请求将失败。 严格的大多数节点被称为 Quorum 。
2 ZooKeeper集合的节点
让我们分析在ZooKeeper集合中拥有不同数量的节点的效果。
- 如果我们有单个节点，则当该节点失败时，ZooKeeper集合失败。 它导致“单点故障”，并且不推荐在生产环境中使用。
- 如果我们有两个节点和一个节点失败，我们没有多数，因为两个中的一个不是多数。
- 如果我们有三个节点和一个节点失败，我们有大多数，所以，这是最低要求。 ZooKeeper集合在实际生产环境中必须至少有三个节点。
- 如果我们有四个节点和两个节点失败，它再次失败，它类似于有三个节点。 额外节点不用于任何目的，因此，最好添加奇数的节点，例如3,5,7。
- 我们知道写入过程比ZooKeeper集合中的读取过程昂贵，因为所有节点都需要在其数据库中写入相同的数据。 因此，与具有用于平衡环境的大量节点相比，具有更少数量的节点(3,5或7)是更好的。
下图描述了ZooKeeper WorkFlow，后面的表解释了它的不同组件。
| 组件 | 描述 |
|---|---|
| 写入 | 写过程是由领导节点处理。领导者转发写请求到所有znodes及其等待来自znodes应答。如果一半的znodes的回复，那么写入过程就完成了。 |
| 读取 | 读取在内部由特定连接znode进行的，所以没有必要与集群交互。 |
| 复制数据库 | 它是用来将数据存储在zookeeper。每个znode都有自己的数据库及其每个znode 在一致性的作用下，每次有相同的数据。 |
| 领导者（节点） | 领导者是由Znode负责处理写请求。 |
| 追随者（节点） | 追随者收到来自客户端的写请求，并将其转发到领导znode。 |
| 请求处理器 | 目前仅在领导节点。它从跟随节点的请求支配写入。 |
| 原子广播 | 负责从领导节点到从节点广播更改。 |
3 Zookeeper 领导选举
让我们来分析一下一个领导节点在ZooKeeper集合的选举。考虑集群中有N多的节点。领导人选举的过程如下：
- 所有节点创建具有相同路径/ app / leaderelection / guid的顺序，临时znode。
- ZooKeeper集合将附加10位序列号到路径，创建的znode将是/app/leader_election/guid_0000000001，/app/leader_election/guid_0000000002等。
- 对于给定的实例，在znode中创建最小数量的节点成为leader ，而所有其他节点是followers。
- 每个从节点监视具有次最小编号的znode。例如，创建znode /app/leader_election/guid_0000000008的节点将观察znode /app/leader_election/guid_0000000007，创建znode /app/leader_election/guid_0000000007的节点将观察znode /app/leader_election/guid_0000000006。
- 如果领导断开，则其相应的znode /app/leader_electionN被删除。
- 下一个在线从节点将通过观察者获得关于leader移除的通知。
- 下一个在线follower节点将检查是否存在具有最小编号的其他znode。如果没有，那么它将承担领导者的角色。否则，它找到创建具有最小编号的znode的节点作为leader。
- 类似地，所有其他跟随节点选择创建具有最小编号的znode作为followers的节点。
领导选举是一个复杂的过程，但ZooKeeper服务使它非常简单。
