【Zookeeper】集群机制

集群机制

半数机制：集群中半数以上机器存活，集群可用。

Zookeeper适合装在奇数台机器上！！！至少3台

选举机制

Zookeeper集群的角色：Leader和 Follower。Leader是通过内部的选举机制临时产生的。

全新集群

如图假设有mini1、mini2和mini3的三台服务器组成的Zookeeper集群，他们的myid分别是1-3，同时他们都是最新启动的，也就是没有历史数据，在存放数据量这一点都是一样的，假设这三台服务器按照顺序启动，则选举机制如下所述：

1. mini1服务器启动，此时他查看自己的配置文件发现集群里面应该有三台服务器，但是他发出去的报文没有任何响应，说明其他两台还没有启动，所以他的选举状态一直是LOOKING状态。
2. mini2服务器启动，他也查看自己的配置文件发现集群里面应该有三台服务器，而且他发出的报文只有mini1能响应，所以他认为集群中目前有两台服务器是启动的。接着他和mini1开始选举，根据id较大胜出原则，mini2被选举为Leader，mini1则为Follower。
3. mini3服务器启动，他也查看自己的配置文件发现集群里面应该有三台服务器。虽然按照id较大胜出原则，他应该是Leader，但是前面已经有半数以上的服务器选举了mini2，所以他只能做Follower了。

这是3台服务器的情况下的选举流程，那如果是5台呢？流程如下所述：

1. 服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。
2. 服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它（这个例子中的半数以上是3），所以服务器1和2还是继续保持LOOKING状态。
3. 服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
4. 服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能是Follower。
5. 服务器5启动，同4一样，只能是Follower。

非全新集群

集群初始化的时候，是按照上述的说明进行选举的，但是当Zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。需要加入数据id、Leader id和逻辑时钟。

1. 数据id：数据新的id就大，数据每次更新都会更新id。
2. Leader id：就是我们配置的myid中的值，每个机器一个。
3. 逻辑时钟：这个值从0开始递增，每次选举对应一个值，也就是说： 如果在同一次选举中，那么这个值应该是一致的 ; 逻辑时钟值越大，说明这一次选举Leader的进程更新。

选举的标准就变成：

1. 逻辑时钟小的选举结果被忽略，重新投票。
2. 统一逻辑时钟后，数据id大的胜出。
3. 数据id相同的情况下，Leader id大的胜出。
   根据这个标准选出Leader。