zookeeper源码分析--0.原理及核心领域概念

假设先不要恢复文件， 单机模式启动 客户端，服务端消息交互，简单的命令查询 伪集群模式选举，加入和离开 数据恢复

技术细节 nio trie

由于文化问题，还是换成我们熟悉的名词。 人大常委会

法官 律师，不是靠嘴皮子，靠举手投票。 不明真相的群众

第一轮举手 第二轮举手 议会选举 自己党派的领导。过程，最多只有一个 过程，最多只有一个value 被批准

批准过后就称为法典

审理 宣判

我还没准备好，那么放弃本轮。

总体约束：每轮提议如果有一半以上审核者同意，那么此轮提议才能批准。 如果某一轮审判中，系统批准了某提议。那么后续每轮审判中，系统只能批准该提议。

3个角色 提议者：每个提议者可以提不同的提议，可以发出 准备提议，进行提议 指令 审核者：审核提议者的提议，可以发出 我还没准备好，同意，拒绝 指令 学习者：学习被批准的建议，可以发出 学习 指令

提议可以理解为“给XXX变量赋值”

稍微注意下这里的用词，“同意”是审核者的行为，“批准”是审核者之间最后协商后的行为。

比如在第b轮中，提议者发出 准备提议 指令， 如果有审核者发出 我还没准备好 ，则此轮结束。 提议者发出 进行提议 指令，
如果一半以上审核者

zab 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过程.

zookeeper3.3.3源码分析(一)工作原理概述 http://www.codedump.info/?p=207 http://www.searchtb.com/2011/01/zookeeper-research.html