zookeeper3.3.3源码分析(一)工作原理概述

hgjgh

zookeeper3.3.3源码分析(一)工作原理概述
　　简单的说一下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>　　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过程.
　　这里只是简单的描述了一下zookeeper集群的工作原理,后面将分别展开来讨论.