美文网首页分布式系统分布式架构
Zookeeper的FastLeaderElection算法分析

Zookeeper的FastLeaderElection算法分析

作者: Jiafu | 来源:发表于2017-09-29 13:06 被阅读93次

    我们知道,在经典的paxos算法中每一个peer都是proposer,但是这就不可避免的产生提案冲突,为了减少这种冲突带来的系统消耗与时间延迟,就产生了Leader这个角色,整个系统中,就只允许Leader可以发出提案。ZooKeeper就是按照这个思路来实现的。本文主要讨论ZooKeeper中的FastLeaderElection算法,来说明Leader是如何产生的。

    我们先要清楚以下几点

    • 一个Server是如何知道其它的Server?
      在ZooKeeper集群中,Server的信息都在zoo.conf配置文件中,根据配置文件的信息就可以知道其它Server的信息。

    • ZooKeeper服务器有哪几种状态?(选主相关的状态)
      LOOKING:寻找leader状态
      LEADING:领导状态(节点为leader)
      FOLLOWING:跟随者状态
      OBSERVING:观察者状态(此状态不参与选举)

    • 成为Leader的必要条件?
      Leader要具有最高的zxid;集群中大多数的机器(至少n/2+1)得到响应并follow选出的Leader。

    • 如果所有zxid都相同(例如: 刚初始化时),此时有可能不能形成n/2+1个Server,怎么办?
      ZooKeeper中每一个Server都有一个ID,这个ID是不重复的,如果遇到这样的情况时,ZooKeeper就推荐ID最大的哪个Server作为Leader。

    • lookForLeader函数什么时候被调用?
      当Server的状态为LOOKING时,lookForLeader就会被调用。具体参见QuorumPeer类的run方法。

    • ZooKeeper中Leader怎么知道Fllower还存活,Fllower怎么知道Leader还存活?
      Leader定时向Fllower发ping消息,Fllower定时向Leader发ping消息,当发现Leader无法ping通时,就改变自己的状态(LOOKING),发起新的一轮选举。

    算法相关的数据结构

    收到的通知的数据结构:

    static public class Notification {
    
    long leader;//被推荐的leader的id
    
      long zxid;//被推荐的leader的事务id        
      long electionEpoch;//推荐者的选举周期
    
      QuorumPeer.ServerState state;//推荐者的状态
    
      long sid;//推荐者的id
    
      long peerEpoch;//被推荐的leader的选举周期
    
    }
    

    发送通知使用数据结构(跟接收其实差不多):

    static public class ToSend {
    
    static enum mType {crequest, challenge, notification, ack}
    
     
      ToSend(mType type,
    
                      long leader,
    
                    long zxid,
    
                    long electionEpoch,
    
                    ServerState state,
    
                    long sid,
    
                    long peerEpoch) {
    
     
                this.leader = leader;
    
                this.zxid = zxid;
    
                this.electionEpoch = electionEpoch;
    
                this.state = state;
    
                this.sid = sid;
    
                this.peerEpoch = peerEpoch;
    
            }
    
            long leader;//推荐的Leader ID
    
            long zxid;//推荐的Leader的最大事务ID
    
            long electionEpoch;// 推荐者本身的选举周期
    
            QuorumPeer.ServerState state;// 推荐者本身的状态
    
            long sid; // 推荐者本身的ID
    
            long peerEpoch; // 推荐的Leader的选举周期
    
    }
    
    

    关键字段、函数解释

    • leader
      所推荐的leader的id。

    • zxid(ZooKeeper transaction id)
      ZooKeeper事务Id,每个ZooKeeper状态的改变都会形成一个新的zxid值,这个值越大表示更新越新。

    • electionEpoch/logicalclock/peerEpoch
      选举周期,用来判断是否为同一次选举。每调用一次选举函数,logicalclock自增1,并且在选举过程中如果遇到election比当前logicalclock大的值,就更新本地logicalclock的值。

    • public Vote lookForLeader() throws InterruptedException
      选举函数,当ZooKeeper Server的状态变为LOOKING时,就会发起选举。函数会阻塞式地进行选主,直到最终的主产生,并返回为最终的投票结果。

    • synchronized void updateProposal(long leader, long zxid, long epoch)
      更新投票

    • private boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch)
      将收到的对方的投票与当前自己的投票对比,判断对方的投票是否优于自己的投票。具体代码:

        protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {
    
            LOG.debug("id: " + newId + ", proposed id: " + curId + ", zxid: 0x" +
    
                    Long.toHexString(newZxid) + ", proposed zxid: 0x" + Long.toHexString(curZxid));
    
            // 使用计票器判断当前server的权重是否为0
    
            if(self.getQuorumVerifier().getWeight(newId) == 0){
    
                return false;
    
            }
    
           
           
            // 通过Epoch、zxid、id来比较两个候选leader
    
            return ((newEpoch > curEpoch) ||
    
                    ((newEpoch == curEpoch) &&
    
                    ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))));
    
        }
    
    

    FastLeaderElection算法(lookForLeader函数的主要逻辑)

    1. 发起一轮投票选举,推举自己作为leader,通知所有的服务器,等待接收外部选票。
    1. 只要当前服务器状态为LOOKING,进入循环,不断地读取其它Server发来的通知、进行比较、更新自己的投票、发送自己的投票、统计投票结果,直到leader选出或出错退出。具体作法:

    从队列中取出一个Notification(选票),则根据消息中对方的状态进行相应的处理。

    1)LOOKING状态:

    a.如果发送过来的逻辑时钟大于目前的逻辑时钟,那么说明这是更新的一次选举投票,此时更新本机的逻辑时钟(logicalclock),清空投票箱(因为已经过期没有用了),调用totalOrderPredicate函数判断对方的投票是否优于当前的投票(判断规则上面提过了),是的话用对方推荐的leader更新下一次的投票,否则使用初始的投票(投自己),调用sendNotifications() 通知所有服务器我的选择,跳到d。

    b.如果对方处于上轮投票,不予理睬,回到2。

    c.如果对方也处于本轮投票,调用totalOrderPredicate函数判断对方的投票是否优于当前的投票,是的话更新当前的投票,否则使用初始的投票(投自己)并新生成notification消息放入发送队列。调用sendNotifications() 通知所有服务器我的选择。

    d.将收到的投票放入自己的投票箱中。

    e.调用计票器的containsQuorum函数,判断所推荐的leader是否得到集群多数人的同意(根据计票器的实现不同,可以是单纯看数量是否超过n/2,也可以是按权重来判断,我们这里假设单纯看数量),如果得到多数人同意,那么还需等待一段时间,看是否有比当前更优的提议,如果没有,则认为投票结束。根据投票结果修改自己的状态。以上任何一条不满足,则继续循环。

    2)OBSERVING状态:

    不做任何事。

    3)FOLLOWING或LEADING状态:

    a.如果选举周期相同(选票是同一轮选举产生),将该数据保存到投票箱,根据当前投票箱的投票判断对方推荐的leader是否得到多数人的同意,如果是则设置状态退出选举过程,否则到b。

    b.这是一条与当前逻辑时钟不符合的消息,或者对方推荐的leader没有得到多数人的同意(有可能是收集到的投票数不够),那么说明可能在另一个选举过程中已经有了选举结果,于是将该选举结果加入到outofelection集合中,再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟,设置状态,退出选举过程。否则继续循环。outofelection用于保存那些状态为FOLLOWING或者LEADING的ZooKeeper节点发送的选票,由于对方的状态为FOLLOWING或者LEADING,所以它们当前不参与选举过程(可能人家已经选完了),因此称为“out of election”。

    参考资料

    分布式设计与开发(三)——高一致性服务ZooKeeper
    Zookeeper全解析——Paxos作为灵魂
    一个不错的讲解zookeeper选举算法

    相关文章

      网友评论

        本文标题:Zookeeper的FastLeaderElection算法分析

        本文链接:https://www.haomeiwen.com/subject/jlriextx.html