zookeeper 集群及其选举机制

zookeeper 集群

zookeeper 集群数据是如何实现同步的?
Zk集群是由多个Server节点组成了一个集群,只有一个Leader节点;其他节点类型都是为Follower类型。

1. 每个Follower节点保存了Leader节点副本数据;
2. 全局保证数据一致性问题,
3. 分布式读写分开写的请求统一交给 Leader 节点实现，Follower或者是ObServer 节点主要实现读的操作:

注意:如果连接的节点类型是一个 Follower 节点或 Observer 节点的情况下做写的操作的时候直接转发到Leader实现写操作。

集群搭建

搭建zk集群配置:

1. 每个zk配置文件需要有myid.
2. 每个zk配置文件中需要配置所有集群的节点

搭建过程:这里以三台zk服务器为例,并且部署在一台电脑上
第一步、配置每个zk节点的配置文件
第一个zk zoo.cfg配置

tickTime=2000
initLimit=10
syncLimit=5
dataDir=D:/Dev/ZooKeeper1/data
dataLogDir=D:/Dev/ZooKeeper1/log
clientPort=2181
// 2888表示：服务器之间的通信端口，3888表示：Leader选举的端口
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

第二个zk zoo.cfg配置

tickTime=2000
initLimit=10
syncLimit=5
dataDir=D:/Dev/ZooKeeper2/data
dataLogDir=D:/Dev/ZooKeeper2/log
clientPort=2181

server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

第三个zk zoo.cfg配置

tickTime=2000
initLimit=10
syncLimit=5
dataDir=D:/Dev/ZooKeeper3/data
dataLogDir=D:/Dev/ZooKeeper3/log
clientPort=2181

server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

第二步、在每个zk的数据目录新建文件 myid ，文件的值为对应的server.x对应的×值，
例如: server.1=127.0.0.1:2888:3888 zk节点的myid的值为:1
注意:每个zk节点的myid不能重复。

第三步、依次启动zk节点即可。

Java客户端连接集群

将各个zk 连接信息用英文逗号分开，如下面代码所示：

private static final String  url="1.11.11.1:2181,1.11.11.2:2182,1.11.11.3:2183";

集群选举策略

节点状态
LOOKING:寻找Leader状态，处于该状态需要进入选举流程
LEADING:领导者状态，处于该状态的节点说明是角色已经是Leader(执行读、写的操作)
FOLLOWING︰跟随者状态，表示Leader已经选举出来，当前节点角色是follower(执行读的操作，写的操作转发给LEADER执行)
OBSERVER:观察者状态，表明当前节点角色是observer， observer角色和Follower角色相似，只不过observer 不能够参与Leader选举。作用:主要不影响本身选举的时间效率，目的时提高客户端读的请求效率。(执行读的操作，写的操作转发给LEADER执行)

事务id (zxid)
Zookeeper状态的每次变化〔也就是写的请求）都接收一个ZXID(Zookeeper事务id)形式的标记。ZXID是一个64位的数字，由Leader统一分配，全局唯一，不断递增。
ZXID展示了所有的ZooKeeper的变更顺序。每次变更会有一个唯一的zxid，如果zxid1小于zxid2说明zxid1在zxid2之前发生。

myid
集群中每台节点的标识，id为zookeeper 提供了一个稳定的标识符

选举原理

ZooKeeper选举实现原理

1. 状态变更服务器启动的时候每个Server的状态都是为“选举状态”，如果当前的leader 的角色宕机之后，非 obServer 角色的节点都会会从新进入到选举。
2. 发起投票的时候,每个Server端都会产生(myid,zxid)投票选举，系统默认初始化的时候zxid为0，如果在运行期间每个Server的zxid 可能不会不同，这取决于最后一次做更新的操作。
3. 接受自己投票实现投票pk
   1.先检查zxid，谁最大谁就是为leader.
   2.如果zxid都是一样的情况下时候，myid谁最大谁就是为leader.
   3.如果有过半机制已经选举出了leader,.之后启动的节点不会加入选举,

zk集群初始化启动期间Leader选举

如果选举的zk节点超过一半之后，已经满足过半机制leader已经选举出来了，后面启动的zk节点不需要重新进行选举的。

在集群初始化阶段，当有一台服务器ZK1启动时，其单独无法进行和完成Leader选举，当第二台服务器ZK2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程开始，过程如下:

(1)、每个Server发出一个投票。由于是初始情况，ZK1和ZK2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid,ZXID)来表示，此时ZK1的投票为(1,0)，ZK2的投票为(2,0)，然后各自将这个投票发给集群中其他机器。

(2）、接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3)、处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下

• 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

• 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

  对于ZK1而言，它的投票是(1, 0)，接收ZK2的投票为(2,0)，首先会比较两者的ZXID，均为0，再比较myid，此时ZK2的myid最大，于是ZK2胜。ZK1更新自己的投票为(2，O)，并将投票重新发送给ZK2。

(4)、统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于ZK1、ZK2而言，都统计出集群中已经有两台机器接受了(2,0)的投票信息，此时便认为已经选出ZK2作为Leader。

(5)、改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。当新的Zookeeper节点ZK3启动时，发现已经有Leader了，不再选举，直接将直接的状态从LOOKING 改为 FOLLOWING。

Zookeeper集群运行期间Leader重新选

在Zookeeper运行期间，如果Leader节点挂了，那么整个Zookeeper集群将暂停对外服务，进入新一轮Leader选举。假设正在运行的有ZK1、ZK2、ZK3三台服务器，当前Leader是ZK2，若某一时刻Leader挂了，此时便开始Leader选举。

(1）、变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
(2）、每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定ZK1的ZXID为124，ZK3的ZXID为123;在第一轮投票中，ZK1和ZK3都会投自己，产生投票(1,124)，(3,123)，然后各自将投票发送给集群中所有机器。
(3）、接收来自各个服务器的投票。与启动时过程相同。
(4）、处理投票。与启动时过程相同，由于ZK1事务ID大，ZK1将会成为Leadero

如何保证zk 集群可用?
答：必须保证过半原则，所以推荐zk 集群节点数量为奇数。

zk集群使用Observer 实现实现扩展

怎么添加observer类型的zk节点?
在配置信息后面添加
server.3=127.0.0.1:2890:3890:observer

有什么作用?
主要不影响zk集群的leader选举时间的效率，目的是提高客户端查询的效率。observer类型的节点不参与 leader 选举。