Zookeeper选主逻辑详细分析-源码解读

Zookeeper选主逻辑详细分析-源码解读 一，选主逻辑先知道

• 1，结点启动后首状态为LOOKING，即选主状态，开始执行选主逻辑；
• 2，如果集群已经有leader，其他结点会将Leader信息返回（如何返回？），则选举结束，进入其他状态（什么状态？）；
• 3，如果集群没有leader，则开始投票，结点首先创建和其他结点的网络连接（如何知道其他结点的IP端口信息？），每个结点内部都有选举的客户端和服务端，由客户端发起连接请求。
• 4，zookeeper规定myid小的不能作为大myid的客户端，所以小myid客户端连接上大myid服务端后，连接会被大myid断开，大myid客户端会尝试建立一个反向连接，即大myid客户端连接小myid服务端。
• 5，连接建立后，进行第一轮投票，第一轮投票都投自己，并将投票结果广播给其他结点，最小myid无法广播，只能接收。小myid服务器接收到大myid广播(投票)后将自己投票作为响应返回给大myid服务器，这就是第一轮投票。
• 6，第一轮投票，所有结点各得自己的一票同时接收到其他节点各自投自己的票，没有任何投票超过半数，继续选举。
• 7，第一轮投票结束后，每个结点从当前选票中按照epoch、zxid、myid的先后顺序根据一定的规则（什么规则?）继续计票，计票结果就是下一轮的投票。

epoch称之为逻辑时钟，其实是选举轮次，因为网络原因，导致某些结点的选票迟到，接收到这些选票的结点如果已经进入下一轮选举，则会放弃这些迟到的选票。每一轮选举结束后，再次投票会自增选举轮次，相同轮次的票才有可比性。

zxid是指事务ID，zookeeper保证事务有序，zxid小的结点说明有数据缺失不能作为leader

myid就是服务器id，通过配置文件指定

• 8，大myid结点将自己的机票结果广播给小myid结点，小myid结点接收到选票后将自己的选票作为响应返回给大myid结点，这样每个结点都有了这一轮的所有选票。
• 9，每个结点接收到选票后就开始计票，如果某个票数超过集群结点的半数，则当前节点的选举结束。
• 10，如果没有超过半数的结点，则继续下一轮投票、计票，直到有超过半数的选票。
• 11，每个结点都选出了leader，但不能保证每个结点选出的leader是同一个leader，所以需要leader确认。

二，带着问题读源码

1，为什么需要选主？
2，何时需要选主？
3，不同结点如何通信（交换选票）？
4，每轮投票何时触发计票？
5，每轮投票何时结束？
6，整个选举过程何时结束？