Zookeeper 集群角色、原理

Zookeeper 的集群角色

集群中的 server 分为三种角色：leader, follower, observer。

• 其中observer是配置zoo.cfg明确定义的，角色leader 在一个zookeeper集群中有且只能有一个，是通过内部的选举机制临时产生的。

• leader 是集群中最重要的角色。负责响应集群的所有对Zookeeper数据状态变更的请求。它会将每个状态更新请求进行顺序管理，以便保证整个集群内部消息处理的 FIFO，遵循了顺序一致性（Sequential Consistency）。

  • leader 内部维护 session ，来自客户端的连接和断开连接，都会被统一follower 或 observer 转发给leader处理。
  • leader 内部维护单调递增的 Zxid（ZooKeeper Transaction Id），针对客户端连接，断开连接，节点的写操作都会分配一个全局唯一的Zxid，同时这些操作是原子性的，并且是严格顺序性的，遵循ZAB原子广播一致性协议完成事务（transaction）操作。如果客户端的所有写操作，都会被 follower 统一转发给leader处理。
• follower 具有选举权。负责提供给客户端读写服务，需要响应leader的提议
• observer 没有选举权。主要提供给客户端读服务，不提供写服务，也不需要响应leader的提议。也不需要日志文件，因为没有写服务，没有持久化的需要。

Server状态

• LOOKING，竞选状态。
• FOLLOWING，随从状态，同步leader状态，参与投票决策提案。
• OBSERVING，观察状态，同步leader状态，不参与投票决策提案。
• LEADING，领导者状态，发起正常消息的提案。

Zookeeper 的存储

zookeeper中的znode数据都是在内存中优先维护和提供读服务，当事务被提交以及最终提交都会持久化到磁盘的日志文件中。

Zookeeper 的内部网络拓扑

Zookeeper 在内部网络中如何实现两两连接的？

这里暂且使用 10.0.2.30，10.0.2.31，10.0.2.32，10.0.2.33 替代 node1，node2，node3，node4，并依次启动 zookeeper。

• zoo.cfg配置文件

server.1=10.0.2.30:2888:3888
server.2=10.0.2.31:2888:3888
server.3=10.0.2.32:2888:3888
server.4=10.0.2.33:2888:3888

依次使用 netstat 查看网络连接情况

• node1

可以看出来 node1作为服务节点，由 node2，node3，node4 通过 3888端口建立连接进来。
node1 作为客户端连接 node3 (目前node3是leader) 的2888端口。

• node2

可以看出来 node2作为服务节点，由 node3，node4 通过 3888端口建立连接进来。
但是 node2 作为客户端连接node1的3888端口。
node2 作为客户端连接 node3 (目前node3是leader) 的2888端口。

• node3

可以看出来 node3作为服务节点，由 node4 通过 3888端口建立连接进来。
但是 node3 作为客户端连接node1，node2 的3888端口。
node3 作为leader节点，由 node1，node2 ，node4 通过 3888端口建立连接进来。
至于为什么 node3能当选 leader 呢？可以在下面的 选举过程中 得到进一步详细的阐述。

• node4

可以看出来 node4 作为客户端连接node1，node2 ，node3 的3888端口。
node4 作为客户端连接 node3 (目前node3是leader) 的2888端口。

• 结论

Zookeeper 在内部网络中如图所示，依据zoo.cfg的配置后续的server都逐个连接前面的server的3888端口，这样就形成了两两连接的拓扑，同时也不冗余。
而当leader当选时，会开放2888端口，其他follower连接其2888端口。

ZAB（原子广播，Zookeeper Atomic Broadcast）

https://zookeeper.apache.org/...

ZAB（Zookeeper Atomic Broadcast）原子广播是 Paxos分布式一致性协议算法（http://zh.wikipedia.org/zh-cn...） 的一个简化版本。

首先有以下概念，我们需要了解：

• 数据包（Packet）：通过 FIFO Channel 发送的字节数组。
• 提案（Proposal）：协议的单位。通过与ZooKeeper中的法定server交换数据包来达成协议。大多数提案都包含消息，但是 NEW_LEADER Proposal 提案是不包含消息。
• 消息（Message）：要自动广播到所有ZooKeeper服务器的字节数组。消息被包含在一个提案（Proposal）中，并且只有在提案（Proposal）被通过后消息才会最终交付delivered（提交到事务日志和更新内存的统一视图）。
• 法定人员 （Quorum）：有 Zookeeper集群中非observer 角色的所有服务器节点组成，具有投票通过提案（Proposal）的权力。

在 Zookeeper 中提供以下的保证数据的严格顺序：

• 传递可靠性：如果一个消息被一个server最终交付delivered，那么这个消息最终也被其他所有的server最终交付delivered，这里指最终一致性。
• 顺序全局性：如果一个消息a先于b被一个server最终交付delivered，那么消息a也是先于b被其他所有的server最终交付delivered。
• 顺序传递性：如果消息a先于b被发送到server，消息b先于c被发送到server，那么消息a也是先于c被server接收的。

如上所述，ZooKeeper保证消息的总顺序，也保证建议的总顺序。

ZooKeeper使用ZooKeeper transaction id (zxid) ，这是一个全局的唯一的ID。提出提案（Proposal）时，所有提案都将附上zxid，进而保证全局的顺序性。

• leader 将提案（Proposal）将发送到所有ZooKeeper服务器。
• 在法定人员（Quorum）收到后，会确认（acknowledge）回复这个提案（Proposal）给leader。

其中确认acknowledge提案（Proposal）表示服务器已将提案（Proposal）持久化到日志中。

稍微注意一下：法定人员（Quorum）收到提案（Proposal），只存在确认（acknowledge），或者因为网络等原因超时响应，不存在反对（reject）。

• 只要一但满足半数以上（大于所有法定人员的一半）确认acknowledge后，leader就会进入正式提交（Commit）。
• 如果提案（Proposal）中包含一条消息，则在提交时将最终交付delivered该消息。

ZooKeeper消息传递包括两个阶段：

• leader选举（Leader activation）：在此阶段，leader被选举出来，集群开始变为对外可用状态，并准备开始提出提案（Proposal）。
• 活动消息传递（Active messaging）：在此阶段，leader开始接受消息（Message），并发起提案（Proposal），协调和决策以提交（Commit）提案（Proposal）。

leader选举

leader产生的条件：

• 具有最新的 Zxid，如果 存在多个server都有最新的Zxid，在投票过程中选取建立网络连接中 myid最大的。
• leader 和其连接的follower的个数必须满足半数以上（大于所有法定人员的一半）。

当集群中任意具有选举权的server发现leader挂了：

• 该 server 会触发NEW_LEADER Proposal 提案，给自己投票，并通过 ZAB 广播给所有连接的 server。

• 接受到 NEW_LEADER Proposal 提案的server，如果有被选举权，则会触发它的投票行为：

  • 先比较zxid，最新的胜出，如果zxid相同，再比较myid，最大的胜出。
  • 最后将胜出的内容，通过 ZAB 广播给所有连接的 server。
• 最终满足leader条件的server，将被选出，同时 follower也被广播获得 Proposal 的提交。

---

以上中的 网络拓扑 为什么 node3能当选 leader 呢？

• node1 启动时，给自己投票，因为其他server尚没启动，因为 node1 依然在LOOKING竞选状态。
• node2 启动完，给自己投票，同时与 node1 交换了Zxid和myid，node2 胜出，但因为没有达到半数以上法定人员，所以node1，node2 依然处于LOOKING竞选状态。
• node3 启动完，给自己投票，同时与 node1 ，node2 交换了Zxid和myid，node3 胜出，也达到半数以上法定人员（3 > 4/2），因此 node3 被选举为 leader。
• node4 启动完，给自己投票，同时与 node1 ，node2 ，node3交换了Zxid和myid，node3的Zxid最新，因此 node4 追随 node3。

活动消息传递

消息的传递一般指写请求。

• 当 follower 接收到 客户端的 写请求后，会转发给 leader顺序处理。
• leader 收到写请求，会检查数据问题，如无问题，创建一个新的提案proposal加入toBeApplied FIFO 队列，内容是写请求的消息，并附上全局的ZXid。
• leader每次toBeApplied FIFO 队列头部取到一个提案proposal，通过 ZAB 广播给所有的 follower，处于 pending 等待回复。
• follower 收到提案proposal后，记录提案proposal持久化到磁盘的日志文件中，然后确认（acknowledge）回复这个提案（Proposal）给leader。
• leader处于 pending 等待回复，一旦收到follower 加上自己的确认（acknowledge）超过半数法定人员（Quorum），就会触发 Commit阶段，发送commit请求给所有的follower，发送info请求所有的observer。

同时，leader将提案proposal放入 committedRequest 队列，并从toBeApplied FIFO 队列移出该 提案proposal。

• follower 收到 Commit后，会更新自己的内存数据，统一数据视图。
• observer收到info后，会更新自己的内存数据，统一数据视图。

---

针对客户端的读请求，则不需要转发给leader处理。
当然如果是客户端的sync命令，则会触发客户端连接的follower或observer向leader请求同步数据状态。

@SvenAugustus(https://www.flysium.xyz/)
更多请关注微信公众号【编程不离宗】，专注于分享服务器开发与编程相关的技术干货：