Zookeeper 工作流程

  一旦Zookeeper集合启动，它将等待来自客户端的连接。客户端将连接到Zookeeper集合中的一个节点。它可以是领导者或追随者节点。一旦连接了客户端，节点将为特定客户端分配会话标识，并向客户端发送确认。如果客户端没有得到确认，它只是尝试连接Zookeeper集成中的另一个节点。一旦连接到节点，客户端将定期向节点发送心跳，以确保连接不会丢失。

  如果客户端想要读取特定的znode，它会向具有znode路径的节点发送一个读取请求，节点通过从自己的数据库中获取它来返回所请求的znode。因此，Zookeeper的读取速度很快。

  如果客户端想要在ZooKeeper集成中存储数据，它会将znode路径和数据发送到服务器。连接的服务器将把请求转发给领导者，然后领导者将向所有追随者重新发出写请求。如果只有大多数节点成功响应，那么写请求将成功，并且成功的返回代码将被发送到客户端。否则，写请求将失败。绝大多数节点被称为仲裁。

Zookeeper集成中的节点

让我们分析Zookeeper集合中节点数量不同的效果。

  如果我们只有一个节点，那么当该节点出现故障时，ZooKeeper集成就会失败。它会导致“单点故障”，不建议在生产环境中使用。

  如果我们有两个节点，而一个节点出现故障，我们也没有多数，因为两个节点中有一个不是多数。

  如果我们有三个节点，而一个节点出现故障，我们就有大多数节点，所以这是最低要求。Zookeeper团队在实时生产环境中必须至少有三个节点。

  如果我们有四个节点，两个节点发生故障，它会再次发生故障，这类似于有三个节点。额外的节点没有任何作用，因此最好以奇数(例如3、5、7)添加节点。

  我们知道，在ZooKeeper集成中，写过程比读过程昂贵，因为所有节点都需要在其数据库中写入相同的数据。因此，对于一个平衡的环境，拥有更少的节点(3、5或7)比拥有大量节点要好。

下图描述了ZooKeeper工作流程，随后的表格解释了它的不同组件

•   写入：写过程由前导节点处理。领导者将写请求转发给所有znodes，并等待znodes的回答。如果一半的znodes应答，则写过程完成。

•   读取：读取由特定连接的znode在内部执行，因此不需要与群集交互。

•   复制数据库：它用于在Zookeeper中存储数据。每个znode都有自己的数据库，在一致性的帮助下，每个znode每次都有相同的数据。

•   领导者：领导者是负责处理写请求的Znode。

•   追随者：追随者从客户端接收写请求，并将它们转发给领导者znode。

•   请求处理器：仅出现在引线节点中。它管理来自跟随器节点的写请求。

•   原子广播：负责将变更从领导者节点广播到追随者节点。