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大的胜出
其他环境搭建可以参考我的其他博客（链接）：
Spark的安装与部署详情（Local模式，Standalone模式，Spank on YARN模式）
