十、Zookeeper （leader）选举机制

zookeeper选举第一次启动：

一、选举一般分为两种情况：

第一种：初始化集群时进行leader选举。

第二种：原来选出的leader挂掉，出现障碍，需要重新选举时。

二、zookeeper节点的4种状态:

  （1）LEADING：说明此节点已经是leader节点，处于领导者地位的状态，差不多就是一般集群中的master。但在zookeeper中，只有leader才有写的权限，其他节点（FOLLOWING）是没有写权限的，只可以读。

（2）LOOKING：选举中，正在寻找leader，即将进入leader选举流程中（等待）。

（3）FOLLOWING：跟随者，表示当前集群中的leader已经选举出来了。

（4）OBSERVING：OBSERVING和FOLLOWING差不多，但不参加投票和选举，接受leader选举后的结果。

三、选举时的具体过程：（如图）

投票开始：首先每个server都有属于自己的一张票。在初始化或者server崩溃数过半的时候，每个server都有一个自身的myid(zookeeper配置文件)。

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING;

（2）服务器2启动，发起一次选举。服务器1和服务器2分别投自己一票并交换投票信息；此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改投票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1,2保持LOOKING；

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1,2更改状态为FOLLOWING,服务器3更改为LEADING；

（4）服务器4启动，发起一次选举。此时1,2,3已经不是LOOKING状态；不会更改选票信息。交换选票结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING;

(5)服务器5启动，同4一样当小弟。

四、三个概念（SID,ZXID,Epoch）：

SID:服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。

ZXID:事物ID。ZXID是一个事物ID,用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”’的处理逻辑有关。

Epoch:每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加。

Zookeeper选举非第一次启动：

当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：

（1）集群中本来就已经存在一个Leader。

对于第一种已经存在Leader的情况，机器试图去选举 Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。

（2）集群中确实不存在Leader。

假设Zookeeper由5台服务器组成，SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举。

                                （EPOCH，ZXID，SID）（EPOCH，ZXID,SID）（EPOCH，ZXID，SID）

SID为1,2,4 的机器投票情况：（1,8,1）                       （1,8,2）                        （1,7,4）

选举Leader规则：   1、EPOCH大的直接胜出

                                2、EPOCH相同，事物id大的胜出

                                3、事物id相同，服务器id大的胜出 

其他环境搭建可以参考我的其他博客（链接）：

Hadoop伪分布式的搭建详情

Hadoop完全分布式的搭建详情

Zookeeper集群的搭建（单机、伪分布式、集群）

Spark的安装与部署详情（Local模式，Standalone模式，Spank on YARN模式）

HadoopHA工作机制（高可用）

HadoopHA环境搭建（保姆篇，手把手搭建）