Leader选举过程

服务器启动过程中的Leader选举

假如有如下一个服务器集群：

依次启动服务器A、B、C、D、E，（服务器myid分别为1,2,3,4,5）选举过程如下：

首先当A服务器启动的时候，发起一次选举，投自己一票，此时服务器的票数为1，整个服务器集群为5台服务器，票数没有达到半数，选举失败，服务器进入LOOKING状态。

当服务器B启动的时候，发起一次选举，服务器A,B都投自己一票，并互相交换选票，服务器A发现服务器B的myid比自己投票选举的大，于是将投票改为服务器2，这是服务器票数为2，没有达到半数，服务器A,B都进入LOOKING状态。

当服务器C启动的时候，发起一次选举，服务器A,B,C都投自己一票，并互相交换选票，服务器A,B发现自己投票的服务器myid都没有服务器C大，于是将自己的投票改为服务器C,这是整个服务器的票数为3，并且都是服务器C,票数超过一半，服务器当选成为Leader,服务器1,2更改服务器状态为FOLLOWING,服务器C的状态改为LEADING

当服务器D启动的时候，发起一次选举，这次服务器A,B,C的状态已经不是LOOKING，不会更改选票信息，交换选票的时候，服务器C有3票，服务器D只有一票，服务器D将自己的状态改为FOLLOWING.

当服务器E启动的时候，过程跟服务器D启动同样原理。

服务器非第一次启动过程选举

当集群中某一个节点出现下面两种情况的时候就会进入选举：

①：服务器初始化启动

②：服务器运行期间无法与Leader保持连接

当一个服务器发起选举的时候就会出现两种情况，第一种就是集群中已经存在Leader，这时候在发起选举的时候就会被告知Leader信息，当前服务器就要跟Leader建立连接，并同步Leader信息。第二种就是集群中Leader服务器真的宕机了或者出现网络波动下线了，这时候就会进行选举。

每一台服务器都有三个重要的标识，SID(服务器唯一ID,跟myid中的相同)，ZXID事务ID,在某一时刻， 集群中的每台机器的ZXID值不一定完全一 致，这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。Epoch：每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加。

假如存在下面的情况，服务器A,B,C,D,E的SID分别1,2,3,4,5，ZXID分别为8,8,8,7,7并且服务器C为Leader，这是服务器C和E同事出现网络波动下线，那么整个Leader选举的过程如下：先比较Epoch，大的直接为Leader,相同则比较ZXID,相同则比较SID大小，大的为Leader.