ZooKeeper 选举机制

ZooKeeper 集群中的选举是为了确保系统的可用性和一致性。在以下情况下，ZooKeeper 需要进行选举：

• Leader 故障： 当当前的 Leader 出现故障或不可用时，需要选举一个新的 Leader 来接管领导权，以确保系统的正常运行。这种情况下，其他 ZooKeeper 服务器会通过一种选举算法选出新的 Leader。

• 新节点加入： 当新的 ZooKeeper 服务器加入集群时，需要选举一个 Leader 来维护集群的状态和数据一致性。新节点会参与选举，并且如果选举成功，它可能成为新的 Leader。

• 集群初始化： 在集群初始化阶段，当第一个 ZooKeeper 服务器启动时，它会尝试成为 Leader。如果此时没有其他节点加入集群，那么它就会成为唯一的 Leader。

我现在的集群中，有三台zk,为什么第二台是领导？

zk01 1

zk02 2

zk03 3

启动第一台，第一台开始选举，自己投自己一票，因为超过半数才有效，所以zk01不是领导，此时的状态是选举中。

启动第二台，先投自己一票，然后第一台开始投票，比较两者之间谁的myid大，谁的大，就投给谁，zk02再得一票，第二台两票，超过了半数，领导出现了zk02.

启动第三台：发现有领导了，投了吧，当follower吧。

ZooKeeper 的选举基本原理如下：

• 选举协议： ZooKeeper 使用的是基于 Paxos 算法的 Zab 协议（ZooKeeper Atomic Broadcast）。在 Zab 协议中，节点分为两种角色：Leader 和 Follower。Leader 负责处理客户端请求和状态变更，而 Follower 则从 Leader 处同步状态。

• 节点状态： 在 ZooKeeper 集群中，每个节点都有一个状态（状态包括LOOKING、FOLLOWING、LEADING、OBSERVING四种）。节点状态的转换由选举过程决定。

选举过程：

当一个节点启动时，它首先会进入 LOOKING 状态，表示它正在寻找 Leader。

在 LOOKING 状态下，节点会向其他节点发送消息，请求它们投票支持自己成为 Leader。

如果收到了大多数节点的投票，那么该节点就会成为 Leader，并将状态切换为 LEADING。

如果一个节点在一定时间内没有收到足够多的投票或者发生了网络分区等情况，它会重新进入 LOOKING 状态，重新发起选举。

在选举过程中，如果某个节点成为 Leader，那么其他节点会将自己的状态切换为 FOLLOWING，并开始与 Leader 同步数据。

投票机制： 在选举过程中，每个节点都有权利投票。节点在投票时会考虑自己的选票以及其他节点的选票，选择投给谁。通常情况下，节点会投给与自己相同或者更新的节点。此外，每个节点只能投一次票，并且一旦投出去就不

Follower（跟随者）和Candidate（候选者）节点区别

在Zookeeper中，Follower（跟随者）和Candidate（候选者）节点是Zookeeper集群中不同角色的节点，它们在集群中扮演着不同的角色和责任。

Follower节点（跟随者）：

  Follower节点是Zookeeper集群中的普通节点，它们的主要责任是参与Leader选举和数据同步。

  Follower节点跟随Leader节点，对客户端的读请求进行处理，并与Leader节点保持数据同步。

  Follower节点只能接收来自Leader节点的消息，并不能主动发起消息。

  Candidate节点（候选者）：

Candidate节点是在进行Leader选举时，从Follower节点中选出的临时候选节点。

候选者节点在Leader选举期间参与投票，如果获得了大多数Follower节点的选票，就会成为新的Leader节点。

候选者节点会在选举超时时间内等待Follower节点的投票结果，如果在超时时间内没有获得足够的选票，就会重新成为Follower节点。

总的来说，Follower节点是普通节点，负责数据同步和处理客户端的读请求；而Candidate节点是在Leader选举期间临时产生的候选者，参与选举过程，有可能成为新的Leader节点。

Leader节点挂掉期间写操作是否会丢失

在Zookeeper中，如果Leader节点挂掉，会触发新的Leader选举过程。在这个过程中，集群中的Follower节点会尝试选举出一个新的Leader节点来接管集群的工作。在Leader节点挂掉期间，写操作不会丢失，因为Zookeeper保证了数据的持久性和一致性。

具体来说，Zookeeper采用了多数投票的机制，确保数据的一致性。在进行写操作时，客户端会将写请求发送给Leader节点，Leader节点会将写请求分发给集群中的Follower节点，并等待大多数节点的确认。只有在大多数节点确认接收到写请求后，Leader节点才会将写操作应用到自身和其他节点的数据中，然后返回响应给客户端。因此，即使Leader节点挂掉，只要大多数节点能够正常运行，写操作就不会丢失，因为新的Leader节点会继续按照多数节点确认的原则进行数据操作。

需要注意的是，如果写操作发生在Leader节点挂掉期间，并且没有足够多的节点进行确认，那么写操作可能会被视为失败，但这并不意味着数据丢失，因为一旦新的Leader节点选举成功，写操作会被重新提交并应用到数据中。