Zookeeper学习之选举机制（首次与非首次启动）心得

一、Zookeeper选举机制（第一次启动）：（5台服务器举例）

1.服务器1启动，发起第一次选举。

	服务器先投给自己一票，然后判断自己的选票够不够总集群的半数以上，不够（1/5），选举无法完成，服务器状态保持为 LOOKING

2.服务器2启动，在发起一次选举。

	服务器1和2先分别给自己投一票然后进行信息的交换，如果此时服务器1发现服务器2的 myid 比自己目前投票选举的（服务器1）大则更改选票推举服务器2。此时服务器1有0票，服务器2有2票（2/5），选举无法完成，服务器1，2状态保持 LOOKING

3.服务器3启动，发起一次选举。

	同理服务器1，2都会更改选票为服务器3.此时服务器1有0票，服务器2有0票，服务器3有3票（3/5）过半，当选为Leader。服务器1，2更改状态为 FOLLOWDING，服务器3更改状态为 LEADING

4.服务器4启动，发起一次选举。

	此时服务器1，2，3已经不是 LOOKING 状态，不会更改选票信息。交换选票结果为：服务器3有3票，服务器4有1票。服务器4服从多数，将自己的状态更改为 FOLLOWING

5.服务器5启动，同4一样。

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

二、Zookeeper选举机制（非第一次启动）：（5台服务器举例）

1.当ZooKeeper集群中的一台服务器出现以下两种情况之一就会开始进入Leader选举：

	服务器初始化启动

	服务器运行期间无法和Leader保持连接

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

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

		机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅只需要和Leader建立联系，并且同步状态

	2）集群中确实不存在Leader

		假设当前5台服务器，服务器3是leader。此时服务器3和5同时挂掉了，其他三台机器就会重新进行选举选举依据如下：

			优先级：（ Epoch  ZXID  SID ）

			a.Epoch大的直接胜出

			b.Epoch相同，事务id：ZXID大的胜出

			c.Epoch、ZXID相同，服务器id：SID大的胜出

三个重要的ID：

	SID：服务器ID，用来唯一标识一台Zookeeper集群中的机器

			每台机器不能重复，和myid一致

	ZXID：事务ID，用来标识一次服务器状态的变更

			在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关

	Epoch：每个Leader任期的代号