ZooKeeper 核心模块工作原理分析

工作原理概述

简单的说一下zookeeper工作的过程,如果对这个过程还不太清楚,或者说对它如何使用等不太清楚的，可以参考一下其他的文章，比如这篇,这一系列的文章将不讲解它如何使用(实际上我也没有在具体项目中使用过，只是简单的配置运行起来大概晓得如何工作而已).

zookeeper有两种工作的模式，一种是单机方式,另一种是集群方式。单机方式不属于这里分析的范畴，因为研究zookeeper的目的就在于研究一个zookeeper集群的机器如何协调起来工作的。

要配置几台zookeeper一起工作,大家在开始必须使用相同的配置文件,配置文件中有一些配置项,但是与集群相关的是这一项:

server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888

这里定义了两台服务器的配置，格式为:

server.serverid=serverhost:leader_listent_port:quorum_port

顾名思义，serverid是本服务器的id，leader_listen_port是该服务器一旦成为leader之后需要监听的端口，用于接收来自follower的请求，quorum_port是集群中的每一个服务器在最开始选举leader时监听的端口，用于服务器互相之间通信选举leader。

需要注意的是，server id并没有写在这个配置文件中，而是在datadir中的myid文件中指定，我理解这么做的目的是:所有的服务器统一使用一个配置文件，该配置文件里面没有任何与特定服务器相关的信息，这样便于发布服务的时候不会出错，而独立出来一个文件专门存放这个server id值。

zookeeper集群工作的过程包括如下几步:

1) 、recovery，这个过程泛指集群服务器的启动和恢复，因为恢复也可以理解为另一种层面上的”启动”–需要恢复历史数据的启动，后面会详细讲解。
2) 、broadcast，这是启动完毕之后，集群中的服务器开始接收客户端的连接一起工作的过程，如果客户端有修改数据的改动，那么一定会由leader广播给follower，所以称为”broadcast”。

展开来说,zookeeper集群大概是这样工作的:

1) 首先每个服务器读取配置文件和数据文件，根据serverid知道本机对应的配置(就是前面那些地址和端口)，并且将历史数据加载进内存中。

2) 集群中的服务器开始根据前面给出的quorum port监听集群中其他服务器的请求，并且把自己选举的leader也通知其他服务器，来来往往几回,选举出集群的一个leader。

3) 选举完leader其实还不算是真正意义上的”leader”,因为到了这里leader还需要与集群中的其他服务器同步数据，如果这一步出错,将返回2)中重新选举leader。在leader选举完毕之后，集群中的其他服务器称为”follower”,也就是都要听从leader的指令。

4) 到了这里，集群中的所有服务器，不论是leader还是follower，大家的数据都是一致的了，可以开始接收客户端的连接了。如果是读类型的请求，那么直接返回就是了，因为并不改变数据；否则，都要向leader汇报，如何通知leader呢？就是通过前面讲到的leader_listen_port。leader收到这个修改数据的请求之后，将会广播给集群中其他follower，当超过一半数量的follower有了回复，那么就相当于这个修改操作哦了，这时leader可以告诉之前的那台服务器可以给客户端一个回应了.

可以看到，上面1)，2)，3)对应的recovery过程，而4)对应的broadcast过程。

FastLeader选举算法

如何在zookeeper集群中选举出一个leader，zookeeper使用了三种算法，具体使用哪种算法，在配置文件中是可以配置的，对应的配置项是：“electionAlg”，其中1对应的是LeaderElection算法、2对应的是AuthFastLeaderElection算法、3对应的是FastLeaderElection算法。默认使用FastLeaderElection算法。其他两种算法我没有研究过，就不多说了。

要理解这个算法，最好需要一些paxos算法的理论基础。

1)、 数据恢复阶段
首先，每个在zookeeper服务器先读取当前保存在磁盘的数据，zookeeper中的每份数据，都有一个对应的id值，这个值是依次递增的，换言之，越新的数据，对应的ID值就越大。

2) 首次发送自己的投票值
在读取数据完毕之后，每个zookeeper服务器发送自己选举的leader。这个协议中包含了以下几部分的数据：

1)、所选举leader的id(就是配置文件中写好的每个服务器的id) ，在初始阶段。每台服务器的这个值都是自己服务器的id，也就是它们都选举自己为leader.

2) 服务器最大数据的id，这个值大的服务器，说明存放了更新的数据。

3)逻辑时钟的值，这个值从0开始递增，每次选举对应一个值，也就是说：如果在同一次选举中，那么这个值应该是一致的 ，逻辑时钟值越大，说明这一次选举leader的进程更新。

4) 本机在当前选举过程中的状态，有以下几种：LOOKING、FOLLOWING、OBSERVING、LEADING、顾名思义不必解释了吧.

每台服务器将自己服务器的以上数据发送到集群中的其他服务器之后，同样的也需要接收来自其他服务器的数据,它将做以下的处理:

1) 如果所接收数据服务器的状态还是在选举阶段(LOOKING 状态)，那么首先判断逻辑时钟值，又分为以下三种情况:
a) 如果发送过来的逻辑时钟大于目前的逻辑时钟，那么说明这是更新的一次选举，此时需要更新一下本机的逻辑时钟值，同时将之前收集到的来自其他服务器的选举清空，因为这些数据已经不再有效了。然后判断是否需要更新当前自己的选举情况。在这里是根据选举leader id，保存的最大数据id来进行判断的，这两种数据之间对这个选举结果的影响的权重关系是：首先看数据id，数据id大者胜出；其次再判断leader id，leader id大者胜出。然后再将自身最新的选举结果(也就是上面提到的三种数据广播给其他服务器)。代码如下：

  if (n.epoch > logicalclock) {  
    logicalclock = n.epoch;  
    recvset.clear();  
    if(totalOrderPredicate(n.leader, n.zxid,getInitId(), getInitLastLoggedZxid()))  
       updateProposal(n.leader, n.zxid);  
    else  
    updateProposal(getInitId(),getInitLastLoggedZxid());  

    sendNotifications();  

其中的totalOrderPredicate函数就是根据发送过来的封包中的leader id，数据id来与本机保存的相应数