Zookeeper架构系列——集群模式

背景

架构图

集群模式详解

客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过该连接发送请求、获取响应、获取监视事件和发送检测信号。如果与服务器的TCP连接中断，客户端将连接到其他服务器。

订购了ZooKeeper。ZooKeeper在每次更新时都会使用一个数字来标记，该数字反映了所有ZooKeeper事务的顺序。后续操作可以使用该顺序来实现更高级别的抽象，例如同步基元。

ZooKeeper速度很快。在“读取主导”工作负载中，它的速度尤其快。ZooKeeper应用程序在数千台机器上运行，在读取比写入更常见的情况下，它的性能最佳，比率约为10：1。

保证

ZooKeeper非常快速且非常简单。但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证。这些是：

顺序一致性-来自客户端的更新将按发送顺序应用。
原子性-更新成功或失败。没有部分结果。
单个系统映像-无论客户端连接到哪个服务器，它都将看到相同的服务视图。也就是说，即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的旧视图。
可靠性-应用更新后，它将从那时起一直存在，直到客户端覆盖更新。
及时性-保证在一定时间范围内，客户端对系统的看法是最新的。

简单的API

ZooKeeper的设计目标之一是提供一个非常简单的编程接口。因此，它仅支持以下操作：

创建：在树中的某个位置创建一个节点

delete：删除节点

exists：测试某个位置是否存在节点

获取数据：从节点读取数据

setdata：将数据写入节点

GetChildren：检索节点的子节点列表

sync：等待数据传播

跨计算机要求
要使 ZooKeeper 服务处于活动状态，必须有大多数可以相互通信的非故障计算机。对于具有 N 台服务器的 ZooKeeper 集成，如果 N 为奇数，则集成能够容忍多达 N/2 个服务器故障，而不会丢失任何 znode 数据;如果 N 为偶数，则集成最多能够容忍 N/2-1 个服务器故障。

群集选项

本节中的选项设计用于服务器集合，即在部署服务器群集时。

• electionAlg ：（无 Java 系统属性）要使用的选举实现。值“1”对应于未经身份验证的基于 UDP 的快速领导者选举版本，“2”对应于经过身份验证的基于 UDP 的快速领导者选举版本，“3”对应于基于 TCP 的快速领导者选举版本。算法 3 在 3.2.0 中是默认的，以前的版本（3.0.0 和 3.1.0）也使用算法 1 和 2。
  注意
  领导者选举 1 和 2 的实现在 3.4.0 中已弃用。由于 3.6.0 只有 FastLeaderElection 可用，因此在升级时，您必须关闭所有服务器并使用 electionAlg=3 重新启动它们（或从配置文件中删除该行）。>

• maxTimeToWaitForEpoch ： （Java 系统属性： zookeeper.leader.maxTimeToWaitForEpoch） 3.6.0 中的新功能：激活领导者时等待投票者 epoch 的最长时间。如果领导者收到来自其投票者之一的 LOOKING 通知，并且它没有收到来自 maxTimeToWaitForEpoch 内多数人的纪元数据包，则它将转到 LOOKING 并再次选举领导者。这可以进行调整以减少仲裁或服务器不可用时间，它可以设置为比 initLimit * tickTime 小得多。在跨数据中心环境中，可以将其设置为类似 2 秒的值。
  initLimit ：（无 Java 系统属性）允许追随者连接并同步到领导者的时间量，以刻度为单位（参见 tickTime）。如果 ZooKeeper 管理的数据量很大，则根据需要增加此值。

• connectToLearnerMasterLimit ：（Java 系统属性：zookeeper。connectToLearnerMasterLimit） 允许关注者在领导者选举后连接到领导者的时间量（以刻度为单位）（参见 tickTime）。默认值为 initLimit。当 initLimit 较高时使用，因此连接到学习器主节点不会导致更高的超时。

• leaderServe ：（Java 系统属性：zookeeper。leaderServes） Leader 接受客户端连接。默认值为“yes”。主计算机协调更新。为了以略有读取吞吐量为代价获得更高的更新吞吐量，可以将领导者配置为不接受客户端并专注于协调。此选项的默认值为 yes，这意味着领导者将接受客户端连接。

  注意
  当一个集合中有三个以上的 ZooKeeper 服务器时，强烈建议打开领导者选择。

• server.x=[hostname]：nnnnn[：nnnnn] etc ： （无 Java 系统属性）构成 ZooKeeper 集合的服务器。当服务器启动时，它通过在数据目录中查找文件 myid 来确定它是哪个服务器。该文件包含 ASCII 格式的服务器编号，并且应与此设置左侧的 server.x 中的 x 匹配。客户端使用的构成 ZooKeeper 服务器的服务器列表必须与每个 ZooKeeper 服务器拥有的 ZooKeeper 服务器列表匹配。有两个端口号 nnnnn。第一个追随者用于与领导者建立联系，第二个追随者用于领导者选举。如果要在一台计算机上测试多个服务器，则可以对每个服务器使用不同的端口。
  从 ZooKeeper 3.6.0 开始，可以为每个 ZooKeeper 服务器指定多个地址（参见 ZOOKEEPER-3188）。要启用此功能，必须将 multiAddress.enabled 配置属性设置为 true。这有助于提高可用性，并为 ZooKeeper 增加网络级别的弹性。当服务器使用多个物理网络接口时，ZooKeeper 能够在所有接口上绑定，并在发生网络错误时运行时切换到工作接口。可以在配置中使用竖线 （‘|’） 字符指定不同的地址。使用多个地址的有效配置如下所示：

server.1=zoo1-net1:2888:3888|zoo1-net2:2889:3889
server.2=zoo2-net1:2888:3888|zoo2-net2:2889:3889
server.3=zoo3-net1:2888:3888|zoo3-net2:2889:3889

注意
启用此功能后，仲裁协议（ZooKeeper Server-Server 协议）将发生变化。用户不会注意到这一点，当任何人使用新配置启动 ZooKeeper 集群时，一切都会正常工作。但是，如果旧的 ZooKeeper 群集不支持 multiAddress 功能（和新的仲裁协议），则无法在滚动升级期间启用此功能并指定多个地址。如果您需要此功能，但还需要从低于 3.6.0 的 ZooKeeper 集群执行滚动升级，则首先需要在不启用 MultiAddress 功能的情况下进行滚动升级，然后使用新配置进行单独的滚动重启，其中 multiAddress.enabled 设置为 true 并提供多个地址。

• syncLimit ：（无 Java 系统属性）允许关注者与 ZooKeeper 同步的时间量，以刻度为单位（参见 tickTime）。如果追随者落后于领导者太远，他们就会被放弃。
  group.x=nnnnn[：nnnnn] ： （无 Java 系统属性）启用分层仲裁构造。x“是组标识符，”=“符号后面的数字对应于服务器标识符。分配的左侧是以冒号分隔的服务器标识符列表。请注意，组必须是不相交的，并且所有组的并集必须是 ZooKeeper 集合。你可以在这里找到一个例子

• weight.x=nnnnn ：（无 Java 系统属性）与“group”一起使用，在形成仲裁时为服务器分配权重。这样的值对应于投票时服务器的权重。ZooKeeper 有几个部分需要投票，例如领导者选举和原子广播协议。默认情况下，服务器的权重为 1。如果配置定义了组，但未定义权重，则值 1 将分配给所有服务器。你可以在这里找到一个例子

• cnxTimeout ：（Java 系统属性：zookeeper。cnxTimeout） 设置为领导者选举通知打开连接的超时值。仅当您使用 electionAlg 3 时才适用。默认值为 5 秒。

• quorumCnxnTimeoutMs ：（Java 系统属性：zookeeper。quorumCnxnTimeoutMs） 设置领导者选举通知的连接的读取超时值。仅当您使用 electionAlg 3 时才适用。默认值为 -1，然后使用 syncLimit * tickTime 作为超时。

• standaloneEnabled ：（无 Java 系统属性） 3.5.0 中的新增功能：设置为 false 时，可以在复制模式下启动单个服务器，单独的参与者可以使用观察者运行，并且集群可以重新配置到一个节点，然后从一个节点向上配置。默认值为 true，以实现向后兼容性。可以使用 QuorumPeerConfig 的 setStandaloneEnabled 方法或通过将“standaloneEnabled=false”或“standaloneEnabled=true”添加到服务器的配置文件来设置它。

• reconfigEnabled ：（无 Java 系统属性）3.5.3 中的新增功能：这控制动态重新配置功能的启用或禁用。启用该功能后，用户可以通过 ZooKeeper 客户端 API 或通过 ZooKeeper 命令行工具执行重新配置操作，前提是用户有权执行此类操作。禁用该功能后，任何用户（包括超级用户）都无法执行重新配置。任何重新配置的尝试都将返回错误。“reconfigEnabled”选项可以设置为服务器配置文件的“reconfigEnabled=false”或“reconfigEnabled=true”，或使用QuorumPeerConfig的setReconfigEnabled方法。默认值为 false。如果存在，则该值应在整个整体中的每个服务器上保持一致。在某些服务器上将该值设置为 true，在其他服务器上将该值设置为 false 将导致不一致的行为，具体取决于被选为领导者的服务器。如果领导者的设置为“reconfigEnabled=true”，则集合将启用重新配置功能。如果领导者的设置为“reconfigEnabled=false”，则集合将禁用重新配置功能。因此，建议在整体中的服务器之间使用一致的“reconfigEnabled”值。

• 4lw.commands.whitelist ：（Java 系统属性：zookeeper.4lw.commands.whitelist） 3.5.3 中的新功能：用户想要使用的逗号分隔的四个字母单词命令列表。必须在此列表中放置有效的四个字母单词命令，否则 ZooKeeper 服务器将不会启用该命令。默认情况下，白名单仅包含 zkServer.sh 使用的“srvr”命令。默认情况下，其余的四个字母的单词命令处于禁用状态：尝试使用它们将获得响应“…未执行，因为它不在白名单中。下面是一个配置示例，该配置启用 stat、ruok、conf 和 isro 命令，同时禁用 Four Letter Words 命令的其余部分：

4lw.commands.whitelist=stat, ruok, conf, isro

zxid 由两部分组成：纪元和计数器。在我们的实现中，zxid 是一个 64 位数字。我们使用高阶 32 位作为纪元，使用低阶 32 位作为计数器。由于 zxid 由两部分组成，因此 zxid 既可以表示为数字，也可以表示为一对整数（epoch、count）。纪元数字代表领导层的变化。每当新领导人上台时，它都会有自己的纪元。我们有一个简单的算法来为提案分配一个唯一的 zxid：领导者只需递增 zxid 即可为每个提案获得一个唯一的 zxid。领导力激活将确保只有一个领导者使用给定的纪元，因此我们的简单算法可以保证每个提案都有一个唯一的 ID。
ZooKeeper 消息传递包括两个阶段：

• 领导者激活 ：在此阶段，领导者建立系统的正确状态并准备开始提出建议。

• 主动消息传递 ：在此阶段，领导者接受要建议的消息并协调消息传递。

如何查看 ZK 集群中的角色

./bin/zkServer.sh status conf/zoo.cfg

可以看到，其中节点 2 为 leader，其他的为 follower。但是如果你按照 zoo1.cfg，zoo2.cfg，zoo3.cfg 的顺序启动，无论你启动多少遍，节点 2 总是 leader，而这时如果把节点 2 关掉，进行查看角色，发现节点 3 成了 leader。

zk集群选举过程

zk 会进行多轮的投票，直到某一个节点的票数大于或等于半数以上，在 3 个节点中，总共会进行 2 轮的投票：

• 第一轮，每个节点启动时投票给自己，那这样 zk1，zk2，zk3 各有一票。
• 第二轮，每个节点投票给大于自己 myid，那这样 zk2 启动时又获得一票。加上自己给自己投的那一票。总共有 2 票。2 票大于了当前节点总数的半数，所以投票终止。zk2 当选 leader。

正常客户端数据提交流程

客户端写入数据提交流程大致为：leader 接受到客户端的写请求，然后同步给各个子节点：

客户端会和所有的节点建立链接，并且发起写入请求是挨个遍历节点进行的，比如第一次是节点 1，第二次是节点 2。

以此类推。

如果客户端正好链接的节点的角色是 leader，那就按照上面的流程走。

那如果链接的节点不是 leader，是 follower 呢，则有以下流程：

如果 Client 选择链接的节点是 Follower 的话，这个 Follower 会把请求转给当前 Leader，然后 Leader 会走蓝色的线把请求广播给所有的 Follower，每个节点同步完数据后会走绿色的线告诉 Leader 数据已经同步完成（但是还未提交）。

当 Leader 收到半数以上的节点 ACK 确认消息后，那么 Leader 就认为这个数据可以提交了，会广播给所有的 Follower 节点，所有的节点就可以提交数据。

整个同步工作就结束了。

ZK 中的过期数据选举
假设还是有一个 3 个节点的集群，zk2 为 Leader，这时候如果 zk2 挂了。zk3 当选 Leader，zk1 为 Follower。这时候如果更新集群中的一个数据。

然后把 zk1 和 zk3 都关闭。然后挨个再重启 zk1，zk2，zk3。这时候启动后，zk2 还能当选为 Leader 吗？

其实这个问题，换句话说就是：在挨个启动 zk 节点的时候，zk1 和 zk3 的数据为最新，而 zk2 的数据不是最新的，按照之前的选举规则的话，zk2 是否能顺利当选 Leader？

答案为否，最后当选的为 zk1。

这是为什么呢。

因为 zk2 的最新 ZXID 已经不是最新了，zk 的选举过程会优先考虑 ZXID 大的节点。这时 ZXID 最大的有 zk1 和 zk3，选举只会在这 2 个节点中产生，根据之前说的选举规则。在第一轮投票的时候，zk1 只要获得 1 票，就能达到半数了，就能顺利当选为 Leader 了。

参考文章

• zookeeper官网