zookeeper的集群内部选举leader

zookeeper选举leader的情形有两种，第一种是集群刚启动的时候，第二种是集群运行中leader脑裂，导致集群中半数follower与leader心跳检测不到，这些情况下需要选举leader

第一种情形，集群刚启动的时候选举leader流程，我们先假设集群中又5台zk服务器，编号分别为1, 2, 3, 4, 5，根据zk的快速选举过程fastleaderelection，需要半数达成一致才能选举出leader，那么这里就需要3台ZK同意，在选举状态中的ZK一定是LOOKING状态的，ZK的状态有四种

public enum ServerState {
        LOOKING, FOLLOWING, LEADING, OBSERVING;
    }

关于选举源码这一块可以参考FastLeaderElection类的lookForLeader方法的while循环那里，下面先说一下集群刚启动的时候选举的流程，假设启动集群的顺序是编号1，2 ，3， 4， 5

1.编号1的zk服务启动，给自己投票，投票消息是（zid，myId）（0， 1），myId是服务器唯一编号，zid在下面解释，这时候因为其他服务器还没启动无法，编号1的服务无法接收到反馈消息，然后进入LOOKING状态

2.编号2的zk服务启动，这时候，会广播一条选举请求，请求消息是（0， 2），这时候会与编号1交换消息，先比对zid，这里发现zid相同，再比较myId，编号2的id比编号1的大所以，编号1会在下一轮修改投票消息为（0， 2），这时候编号1和编号2都一致投票编号2，但是这时候编号2才获得两票，无法成为leader

3.编号3的ZK服务启动，这时候广播一条选举请求，请求消息为（0,3），与编号1,2互相交互选举信息，先比对zId再比对myId，最后一致认为编号3的服务最大，编号1和编号2的投票信息改成（0,3），这时候编号3获得3票，编号3成为leader，编号1,2的zk服务把LOOKING状态改成follower

4.编号4启动，已经有leader了，从leader那边同步信息，成为follower

5.编号5服务启动，同编号4

这个就是ZK集群服务器启动的时候的选举流程，下面解释一下，zId这玩意

zId，有三个值，一个cZid（对应为节点创建时间），一个是mZid（对应为节点修改时间），pZid（改节点的子节点对应变化时间，与更下级的子节点没有关系）

在zk选举中的zId是zk集群中一次事物变化后累加的值，当服务启动从0开始，后面在集群顺利运行过程中（已经选举出leader，没有选举出leader的话zk集群是无法工作的），当leader广播一次事物，最后半数通过，成功提交一次事物，那么zId就会加1，那么可见，我们能通过这个zId保证选举出事物最新的一台，防止那些旧的，没有最新数据的zk服务器成为leader

以上累加这个是我自己想出来的，网上很多文章对这个有不同解释，具体可以参考《从Paxos到Zookeeper分布式一致性原理与实践》这本书，查看zk选举的章节

先说一个问题，就是zk集群中必须要有半数的节点存活才能，整个zk集群才能正常运行，否则无法选举出leader，以前我认为5台zk中，脑裂两台包括leader也脑裂了（脑裂就是其他节点无法通过心跳检测到zk机器），那么剩下三台zk中，有两台半数通过就能选举出leader其实不然，仔细看看上面所讲的选举过程就知道，leader的选举还是三台一致性投票同意。

那么下面讲一讲在zk集群运行过程中leader脑裂的场景，同样假设5台zk集群，假设脑裂两台机器包括leader也脑裂了

那么看到这里，我想对leader和follower角色都有了解了，其中还有一个Observer角色，Observer充当观察者角色，观察zk集群的最新状态变化并将这些状态同步过来，对于非事务请求可以进行独立的处理，对于事务请求，则会转发给Leader服务器进行处理，Observer不会参与任何形式的投票，包括事务请求Proposal的投票和Leader选举的投票。Observer并非必须的，它是对整个zk的一个优化，如果要部署需要单独指定，可以参考这边文章https://blog.csdn.net/qianshangding0708/article/details/50160891

在leader脑裂之后，整个集群不能正常运行，ZK集群除了Observer之外全部进入了LOOKING状态，重新进行选举，选举的过程同上面一样，只不过这时候zId值可能有高有低，这时候zId的作用就非常之大了，一定是最大的zId会被选举成为leader，因为这样才能保证最新的节点成为leader之后其他旧的zId的的zk节点能同步到最新