Question

Zookeeper和Consul在实现leader election时的区别

Answer 1

每个机器节点加入，都发起一次Vote。
zookeeper server节点接受到新一轮的Vote，都返回上一轮的Leader选举的最后Vote结果。如果处于LOOKING，比如第一次加入的机器，则Vote自己
发起Vote的机器，收集完所有server的Vote结果(包括自己)，统计一下结果，并且判断一下是否超过半数Java代码 if (result.winningCount > (self.getVotingView().size() / 2)) 注意：这里的>号，所以如果单台机器启动，无法通过给自己Vote，使自己成为Leader。一定要>=2台机器的参与
如果没有超过半数，则记录一下本次的投票结果。下一次Vote时，就直接投给上一轮票数最高的Vote，继续进入步骤3
说明： myid序号大的在Vote选举时比较有优势，同样的票数winner会是myid最大的server，从而保证每次的Vote必然会产生一个唯一的winner。
FastLeaderElection算法：
每个机器节点加入，都向外部建议自己做为Leader。zookeeper server接受到请求后，进行一个抉择： Java代码 if ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId))) 判断当前的zxid和myid是否大于当前Vote，如果是则更新之，并同样广播给所有的server。注意： Notification中有个epoch标志，表明当前发起的Vote的传递的次数。比如A发给B，B更新了自己的Vote后，再发给C。这时发的通知中epoch=2。 有点类似图论里的概念，如果notice.epoch < 当前最后一次更新Vote的epoch，则不做任何处理。一个逐步收敛的有向环图单个机器上收到了其他所有机器的Vote结果后，判断出最后的winner结果
Leader处理：
启动LearnerCnxAcceptor，监听Follower的请求。针对每个链接的Follower，开启一个新线程LearnerHandler进行处理
然后针对所有的LearnerHandler，while(true)进行心跳检查ping。针对每次ping结果，针对有ack响应的结果进行vote统计，如果发现超过半数失败，则退出当前的Leader模式，这样又是发起新一轮的选举
Follower处理：
建立socket，链接到Leader server上发起一次syncWithLeader同步请求，此时Leader会根据当前的最大的zxid对比客户端的zxid，发送DIFF/TRUNC/SNAP指令给follower上，保证follower和leader之间的数据一致性。同步完成后，就进入while(true){read , process}的工作模式，开始接受Leader的指令并处理PING : 响应AckPROPOSAL : 记录到自己的缓冲队列pendingTxns中，等待sync指令后刷新到zkDataBase中。有点类似2PC阶段事务COMMIT : 刷新pendingTxns中的对应记录SYNC : 客户端的同步request请求Observer处理：建立socket，链接到Leader server上发起一次syncWithLeader同步请求同
步完成后，进入while(true){read ,
process}的工作模式，和Follower有点不同，主要在于其不处理PROPOSAL/COMMIT等2PC阶段。只接受
INFORM，Leader告诉最终的更新结果，Observer直接提交到zkDataBase中。