一、zookeeper 初始化：

在Zookeeper启动期间,首先会进行数据初始化工作，用于将存储在磁盘上的数据文件加载到Zookeeper

服务器内存中，主要包括了从快照文件中加载快照数据和根据事物日志进行数据订正两个过程。以下是Zookeeper数据初始化的过程。

    1.FileTxnSnapLog是Zookeeper事务日志和快照数据访问层，内容中有FileTxnLog(事务日志管理器)初始化

FileSnap(快照数据管理器)初始化。

    2.构建内存数据库ZKDatabase，首先构建一个初始化DataTree,创建一些Zookeeper默认节点/./zookeeper,/zookeeper/quota

3.PlayBackListener监听器主要用来接收事务应用过程中的回调？

4.反序列化快照文件，并进行文件的checksum校验以确定快照文件的正确性。

5.获得快照最新ZXID（zxid_for_snap），获取事务日志ZXID比zxid_for_snap大的事务，将根据事务日志更新对应的数据，更新完所有事务日志将获得事务最大ZXID(lastProcessedZxid)每当有一个事务被应用到内存数据库中去后,Zookeeper同是回调PlayBackListener监听器，将这一事务操作记录转换成Proposal，并保存到ZKDatabase.committedLog中，以便Follower进行快照同步。

6.epoch:纪元、时代。标识当前Leader周期。每次选举产生一个新的Leader服务器之后，就会生成一个新的epoch。在运行期间集群中机器相互通信的过程中，都会带上这个epoch以确保彼此在同一个Leader周期内。

二、zookeeper各个服务器角色：

在Zookeeper集群中，分别有Leader、Follower和Observer三种类型的服务器角色。其中非Leader也称为Leaner服务器。

1.Leader

Leader服务器是整个Zookeeper集群工作机制中的核心，其主要工作有以下两个：

1）事务请求的唯一调度和处理者，保证集群事务处理的顺序性。

2）集群内部各服务器的调度者。

 使用责任链模式来处理每个客户端请求是Zookeeper的一大特色。

    请求处理链：

Leader请求处理链

非事务请求将直接提交给CommitProcessor否则将除了将请求提交给CommitProcessor外，根据请求类型创建对应的Proposal提议，并发送给所有的Follower服务器来发起一次集群内的事务投票。同时，讲过失去请求交付给SynRequestProcessor进行事务日志的记录以及事务的快照。

LearnerHandler：

    为了保持很整个内部的实时通信，Leader服务器会与每一个Follower/Observer服务器都建立一个TCP长连接，同时也会为每个Follower/Observer服务器都创建一个名为LeanerHandler的实体。LeanerHandler是Learner服务器的管理器，主要负责Learner服务器与Leader服务器之间的网络通信，包括数据同步、请求转发和Proposal提议的投票等。

2.Follower

Follower服务器是Zookeeper集群的跟随者，其主要工作有以下三个：

1）处理客户端非事务请求，转发事务请求给Leader服务器。

2）参与事务请求Proposal的投票。

3）参与Leader选举投票。

        由于不需要负责对事务请求的投票处理，因此相对来说Follower服务器的请求处理链会简单一些，如下：

Follower请求处理链

FollowerRequestProcessor是Follower服务器的第一个请求处理器，其主要工作就是识别出当前请求是否是事务请求。如果是事务请求则将请求发送给Leader服务器。

SendAckRequestProcessor承担事务日志记录反馈的角色，在完成事务日志记录后，会向Leader服务器发送ACK消息以表明自身完成了事务日志的记录工作。

3.Observer

        该服务器充当一个观察者的角色，观察Zookeeper 集群的最新状态变化并将这些状态变更同步过来，与Follower唯一区别是Observer不参与任何形式的投票，包括事务请求Proposal的投票和Leader选举投票。

        Observer请求处理链，如下：

Observer请求处理链

zookeeper leader选举：

1.Leader选举概述：

每个服务器都会以（myid,ZXID）的方式发起投票，每个zookeeper服务器都会有一个myid,且唯一。

   选举流程：

    1）每个server都会发出一个投票

    2）接收来自各个服务器的投票

    3）处理投票：

优先检查ZXID如果，其他ZXID比自己ZXID大，则更新自己的投票

如果ZXID相同，则比较myid,如果自己myid最大，则不更新自己的投票，否则将更新。

    4）统计投票：投票过半

5）改变服务器状态

如果运行中Leader挂掉，则先修改非Observer服务器的状态为Locking，在进行Leader选举流程。

2.Leader算法分析：

SID:  服务器ID ,ZXID: 事务ID, Vote: 投票， Quorum: 过半机器数 quorum=(n/2+1)

集群中已经存在Leader服务器，则会被告知当前Leader的信息，将不进行Leader的选举。

1）每个server都会发出（SID，ZXID）的投票

2）收到各个服务器投票（vote_sid, vote_zxid）

3)    vote_zxid>self_zxid ,投票（vote_sid,vote_zxid）

vote_zxid=self_zxid，vote_sid>self_sid,投票（vote_sid,vote_zxid）

否则将不进行投票

      4)    统计过半的投票

        总之，通常那台服务器上的数据越新，那么将越有可能成为Leader，原因很简单，数据越新，那么它的ZXID也就越大，也就是越能够保证数据的回复。当然，如果集群中几个服务器具有相同的ZXID,那么SID较大的那台服务器成为Leader。

3.Leader实现细节：

    服务器状态：QuorumPeer.ServerState状态，

LOOKING（寻找Leader状态），FOLLOWING，LEADING，OBSERVING

投票数据结构：Vote（id,zxid,electionEpoch(逻辑时钟，每进入新一轮的投票后，都会对改制进行加1操作) peerEpoch被推举的Leader的epoch?,state）

QuorumCnxManager：每台服务器启动的时候，都会启动一个QuorumCnxManager,负责各台服务器之间的底层Leader选举过程中的网络通信。这个类内部维护了一系列的队列，用于保存接收到的、待发送的消息，以及消息的发送器。除接受队列以外，这里提到的所有队列都有一个共同点—按SID分组形成队列集合，假设集群中除自身外还有4台机器，那么当前服务器就会为这4台服务器分别创建一个发送队列，互不干扰。

recvQueue: 消息接收队列，用于存放那些从其他服务器接收到的消息。

queueSendMap:消息发送队列，用于保存那些待发送的消息。是Map，按照SID进行分组，分别为集群中的每台机器分配一个单独队列，从而保证各台机器之间的消息发送互不影响。

senderWorkerMap:发送器集合，每个SendWorker消息发送器，都对应一台远程Zookeeper服务器，负责消息的发送。

lastMessageSent:最近发送过的消息。为每个SID保留最新的发送消息。

    QuorumCnxManager在启动的时候，会创建一个ServerSocket来监听Leader选举的通信端口。开启端口监听后，Zookeeper就能够不断的接受到来自其他服务器的创建连接请求，在接收到来自其他服务器的TCP连接请求时，会交由receiveConnection函数来处理。

为了避免两台机器之间重复地创建TCP连接，Zookeeper设计一种建立TCP连接的规则：只允许SID大的服务器主动和其他服务器建立连接，否则断开连接。如果当前服务器的SID创建相应的消息发送器SendWorker和消息接收器RecvWorker ,并启动他们。

RecvWorker只需要不断从这个TCP连接中读取消息，并将其保存到recvQueue队列中。

SendWorker只需要不断地从对应的消息发送队列中获取出一个消息来发送即可，同时将这个消息放入lastMessageSent中来作为最近发送过的消息。如果当前远程服务器的消息发送队列为空，那么这个时候就需要从lastMessageSent中取出一个最近发送过的消息来进行再次发送。这个细节的处理主要是为了解决这样一类的分布式问题：接受方在消息接受前，或者是在接收到消息后服务器挂掉了，导致消息尚未被正确处理。那么如此重复发送是否会导致其他问题呢？当然，这里可以放心的一点是，Zookeeper能够保证接收方在处理消息的时候，会对重复消息进行正确的处理。

 Leader选举算法实现的流程示意图