zookeeper源码分析之leader选举

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: zookeeper提供顺序一致性、原子性、统一视图、可靠性保证服务zookeeper使用的是zab(atomic broadcast protocol)协议而非paxos协议zookeeper能处理并发地处理多个客户端的写请求,并且以FIFO顺序commit这些写...
zookeeper提供顺序一致性、原子性、统一视图、可靠性保证服务
zookeeper使用的是zab(atomic broadcast protocol)协议而非paxos协议
zookeeper能处理并发地处理多个客户端的写请求,并且以FIFO顺序commit这些写操作,zab采用了一个事务ID来实现事务的全局有序性,
在Zab协议的实现时,分为三个阶段:
1、 Leader Election
2、 Recovery Phase
3、 Broadcast Phase

今天就先分析选举算法的源码实现

zookeeper默认选举算法为FastLeaderElection.java。其主要方法为FastLeaderElection.lookForLeader,该接口是一个同步接口,直到选举结束才会返回。选举的结果保存在类Vote中


选举整体过程主要流程可概括为下图:

来看源码实现

1.//首先logicalclock自增, 在这里logicalclock表示本次选举的id,逻辑时钟的值,这个值从0开始递增,每次选举对应一个值,如果在同一次选举中,这个值是一样的,逻辑时钟值越大,说明该节点上的这一次选举leader的进程更加新

  1. synchronized(this){  
  2.    logicalclock++;  
  3.     //如果自己不是OBSERVER,则投给自己    
  4.    updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch());  
  5. }  

2.sendNotifications();向所有的node发送notification消息,其主方法:

  1. ToSend notmsg = new ToSend(ToSend.mType.notification,proposedLeader, proposedZxid,logicalclock,QuorumPeer.ServerState.LOOKING,sid,proposedEpoch);  
  2. 消息格式:  
  3. mType  type     消息类型  
  4. long   leader     推荐的leader的id,就是配置文件中写好的每个服务器的id  
  5. long   zxid         推荐的leader的zxid,zookeeper中的每份数据,都有一个对应的zxid值,越新的数据,zxid值就越大  
  6. long   epoch,     logicalclock  
  7. ServerState state,  本节点的状态  
  8. long    sid         本节点的 id,即myid  
发送完添加到到发送队列中

3.当该节点的状态为LOOKING且没有stop时,就一直loop到选出leader为止

  1. //从消息队列中接收消息  
  2. Notification n = recvqueue.poll(notTimeout, TimeUnit.MILLISECONDS);  
  3. //如没有接收到消息,则检查manager.haveDelivered(),如果已经全部发送出去了,就继续发送,一直到选出leader为止。否则就重新连接。  
  4. if(manager.haveDelivered()){  
  5.         sendNotifications();  
  6.     } else {  
  7.         manager.connectAll();  
  8.     }  
  9.     int tmpTimeOut = notTimeout*2;//延长超时时间    
  10.     notTimeout = (tmpTimeOut < maxNotificationInterval? tmpTimeOut : maxNotificationInterval);  

4.如果收到回应消息,则检查回应应状态,回应状态有以下四种:LOOKING、OBSERVING、FOLLOWING、LEADING
5.下面分析最核心的LOOKING状态:
  1. case LOOKING:  
  2. // If notification > current, replace and send messages out  
  3. if (n.electionEpoch > logicalclock) {//该节点的epoch大于 logicalclock,表示当前新一轮的选举  
  4.    logicalclock = n.electionEpoch;//更新本地的logicalclock  
  5.    recvset.clear();//清空接收队列recvset  
  6. //调用totalOrderPredicate决定是否更新自己的投票,依次比较选举轮数epoch,事务zxid,服务器编号server id(myid)    
  7.    if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,getInitId(), getInitLastLoggedZxid(), getPeerEpoch())) {  
  8.        updateProposal(n.leader, n.zxid, n.peerEpoch);//把投票修改为对方的  
  9.    } else {  
  10.        updateProposal(getInitId(),getInitLastLoggedZxid(), getPeerEpoch());  
  11.    }  
  12.    sendNotifications();//广播消息  
  13. else if (n.electionEpoch < logicalclock) {//如果该节点的epoch小于logicalclock,则忽略  
  14.    break;  
  15. else if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,proposedLeader, proposedZxid, proposedEpoch)) {  
  16.    updateProposal(n.leader, n.zxid, n.peerEpoch);  
  17.    sendNotifications();  
  18. }  
  19. recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));//把从该节点的信息发到recvset中,表明已经收到该节点的回应  
  20. //通过termPredicate函数判断recvset是否已经达到法定quorum,默认超过半数就通过  
  21. if (termPredicate(recvset, new Vote(proposedLeader, proposedZxid, logicalclock, proposedEpoch))) {  
  22. // Verify if there is any change in the proposed leader  
  23.    while((n = recvqueue.poll(finalizeWait, TimeUnit.MILLISECONDS)) != null){//循环,一直等新的notification到达,直到超时  
  24.        if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, proposedLeader, proposedZxid, proposedEpoch)){  
  25.            recvqueue.put(n);  
  26.            break;  
  27.        }  
  28.    }  
  29.   if (n == null) {//确定leader  
  30.        self.setPeerState((proposedLeader == self.getId()) ?ServerState.LEADING: learningState());  
  31.        Vote endVote = new Vote(proposedLeader, proposedZxid, proposedEpoch);  
  32.        leaveInstance(endVote);//清空接收队列  
  33.        return endVote;  
  34.    }  
  35. }   
  36.   
  37.   
  38.    /* 
  39.      *  
  40.      *  返回true说明需要更新数据 
  41.      * We return true if one of the following three cases hold: 
  42.      * 1- New epoch is higher 
  43.      * 2- New epoch is the same as current epoch, but new zxid is higher 
  44.      * 3- New epoch is the same as current epoch, new zxid is the same 
  45.      *  as current zxid, but server id is higher. 
  46.      */  
  47. protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {  
  48. ...   
  49.    return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))));  
  50. }  


zookeeper的leader算法类似于公民选举,每一个节点(选民),他们都有自己的推荐人(自己)。谁更适合成为leader有一个简单的规则,例如zxid(数据新)、sid/myid(服务编号大)。每个选民都告诉其他选民自己目前的推荐人是谁,当选民发现有比自己更适合的人时就转而推荐这个更适合的人。最后,过半数人意见一致时,就可以结束选举。当然,如果大多数人已经选举出了leader,那剩下的选民(无论是否参与投票)就只能接受已经选出的leader。


watch注意事项
1.Zookeeper客户端可以在znode上设置Watch。znode发生的变化会触发watch然后清除watch。当一个watch被触发,Zookeeper给客户端发送一个通知,当ZooKeeper客户端断开和服务器的连接,直到重新连接上这段时间你都收不到任何通知。如果你正在监视znode是否存在,那么你在断开连接期间收不到它创建和销毁的通知。

2.Zookeeper的客户端和服务会检查确保每个znode上的数据小于1M,因为Zookeeper为了提供高吞吐量,保存到内存里的数据量不宜过多


转载请注明来源:http://blog.csdn.net/odailidong/article/details/41855613


相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
4月前
|
存储 负载均衡 算法
深入浅出Zookeeper源码(七):Leader选举
对于一个分布式集群来说,保证数据写入一致性最简单的方式就是依靠一个节点来调度和管理其他节点。在分布式系统中我们一般称其为Leader。
168 6
|
3月前
|
消息中间件 分布式计算 算法
深入理解Zookeeper系列-3.Zookeeper实现原理及Leader选举源码分析(上)
深入理解Zookeeper系列-3.Zookeeper实现原理及Leader选举源码分析
51 0
|
2月前
|
存储 缓存 Java
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】
20 0
|
4月前
|
存储 缓存 Java
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】(2)
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】
32 0
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】(2)
|
5月前
|
算法 Linux
分布式系列教程(14) -分布式协调工具Zookeeper(集群选举策略)
分布式系列教程(14) -分布式协调工具Zookeeper(集群选举策略)
57 0
|
3月前
|
监控 算法 网络协议
深入理解Zookeeper系列-3.Zookeeper实现原理及Leader选举源码分析(下)
深入理解Zookeeper系列-3.Zookeeper实现原理及Leader选举源码分析
35 1
|
4月前
|
存储 缓存 Java
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】(1)
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】
33 0
【Zookeeper】Apach Curator 框架源码分析:后台构造器和节点操作相关源码分析(二)【Ver 4.3.0】(1)
|
4月前
|
缓存 Java 容器
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】(2)
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】
48 0
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】(2)
|
4月前
|
安全 Java API
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】(1)
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】
65 0
【Zookeeper】Apach Curator 框架源码分析:初始化过程(一)【Ver 4.3.0】(1)
|
11天前
|
监控 负载均衡 Cloud Native
ZooKeeper分布式协调服务详解:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析ZooKeeper分布式协调服务原理,涵盖核心概念如Server、Client、ZNode、ACL、Watcher,以及ZAB协议在一致性、会话管理、Leader选举中的作用。讨论ZooKeeper数据模型、操作、会话管理、集群部署与管理、性能调优和监控。同时,文章探讨了ZooKeeper在分布式锁、队列、服务注册与发现等场景的应用,并在面试方面分析了与其它服务的区别、实战挑战及解决方案。附带Java客户端实现分布式锁的代码示例,助力提升面试表现。
30 2