zk QuorumPeer分析3 选举机制 消息响应机制

参考

• 浅析Zookeeper的一致性原理::选主
• zookeeper的Leader选举机制详解 分析了选举的几个关键函数
• 分析了几个变量的作用

开头

此章研究WorkerReceiver和FastLeaderElection的响应模式， 进而分析其选举机制。面对其他服务器发来的不同数据，我们要判断其状态，并以此调整自己的状态、返回消息。我们要研究zookeeper选举时是如何根据消息进行响应的。

我们要研究，主线程在FastLeaderElection::lookForLeader以及WorkerReceiver::run是如何根据输入数据的不同进行响应的，图形化表示就是如下部分：

判断是否选举成功 termPredicate

protected boolean termPredicate(Map<Long, Vote> votes, Vote vote) {
        SyncedLearnerTracker voteSet = new SyncedLearnerTracker();
        voteSet.addQuorumVerifier(self.getQuorumVerifier());
        if (self.getLastSeenQuorumVerifier() != null
                && self.getLastSeenQuorumVerifier().getVersion() > self
                        .getQuorumVerifier().getVersion()) {
            voteSet.addQuorumVerifier(self.getLastSeenQuorumVerifier());
        }

        /*
         * First make the views consistent. Sometimes peers will have different
         * zxids for a server depending on timing.
         */
        for (Map.Entry<Long, Vote> entry : votes.entrySet()) {
            if (vote.equals(entry.getValue())) {
                voteSet.addAck(entry.getKey());
            }
        }

        return voteSet.hasAllQuorums();
    }

1. 先定义一个SyncedLearnerTracker
2. 往对象里加QuorumVerifier，实际上一般只有一个QuorumMaj
3. 调用voteSet.hasAllQuorums()，若所有添加的QuorumVerifier都判断voteSet通过要求，则返回true。实际上只有QuorumMaj在判断。

选举流程

各种变量含义

• 为什要区分acceptedEpoch 和 currentEpoch
• n.peerEpoch 从FastLeaderElection::getPeerEpoch可知，其含义与currentEpoch等同，只是后者在选票消息中的名字。
• n.electionEpoch 含义与logicalclock等同，只是后者在选票中的名字。
• logicalclock虽然开始时为0，但在发送选票的过程中，若收到更新的logicalclock，则会将自己的LC与之统一。每次调用lookForLeader，都会导致LC加1。按这个道理，LC的含义或许是：当前集群的生存周期数吧？不太明白
  • 思考后认为，logicalclock是用来帮助区分选举轮数的。每次启用选举算法，LC自增1。
  • 阅读lookForLeader的逻辑可知：
    • 你应当加入到一个最新的选举中(旧的选举都作废)
    • 但如果你加入到了一个运行的集群，不管它们的LC版本如何，你都应当加入它们，并将自己的LC与之统一
      • 举个例子，原本leader的LC假设是10，当leader失去与所有follower的联系，且follower都重启过后，follower各自的LC为1，且选举出了新leader。旧leader进入新一轮选举，即使LC是最大的，但它会收到很多LC为1的follower的消息，旧leader就知道自己已经加入到了一个完整的集群了，便将自己的LC与之统一。

集群产生条件

我们看到上图橘色方块的三个出口，可知节点认为自己处于集群中，需要满足三个条件之一：

1. 若收到同一轮投票，且投票所指服务器票数过半，则等待是否有更好的投票：
   1. 如果一定时间内没更好的选择，就确立leader
   2. 如果一定时间内有更好选择，就再等待一遍
2. 若收到自称集群身份(follower/leader)的消息，则看是否同一轮：
   • 如果是同一轮，先当做选票仓，查看选票仓是否票数过半，如果是，就确立leader，如果不是，就到下一步
   • 如果不是同一轮，或者从上一步判断到此，则都先设置outofelection(我称之为leader指认仓)。
     • 如果指认仓票数过半，且checkLeader成功，则视为确立leader。
     • 如果指认仓不能票数过半 ，则重新循环，继续收听选票。