Zookeeper选举过程描述与状态迁移

F1.FastLeaderElection类初始过程

?

1. QuromCnxManager是一个相对底层的”链接”处理类,他负责管理当前server和其他server的socket链接,以及socket上数据的输入输出,对于FastLeader选举过程中所造成的消息发送和接受,均由此manager处理,它维持当前server和其他server建立的链接,以及侦听选举端口上,其他server的链接申请或者数据IO;链接为socket链接,非NIO长连接."链接"的作用,就是为选举过程中所发生的数据交互进行IO操作(例如,接收选举数据和发送头片数据等).
2. 为了避免大量server之间互相建立socket链接,造成性能问题(甚至是不必要的重复链接),manager对链接的控制采取了一种” challenge”(挑战)方式,让任意2个server之间只有一个socket链接,而且总是sid较小的server作为socket server端,sid较大的作为sock client端,在整个分布式网络中,将这种有序有向的链接逐个节点传递下去.不过在初次通信时,server会尝试和所有的其他server发起链接,对于链接的socket server端,来决定是否接受(accept)链接.如果当前server发现socket终端的sid比自己的sid小,那么当前server就会放弃已经建立的链接(假如已经建立)或者关闭此socket,并主动向sid较小的server发起socket链接.选举过程中,如果socket超时或者其他原因终端,链接将会重建.

?

F2.QuorumCnxManager内部结构

?

1. Notification:”通知”,其他server发送的消息,包括server所提议(推选)的leader所具有的如下属性:leader(机器id),,zxid,peerEpoch;以及”提议者”的sid,serverState,electionEpoch.
2. ToSend:”发件”,当前server需要发给其他server的消息,包括它提议的leader所具有的如下属性:leader(机器id),zxid,peerEpoch,以及当前server的如下属性:electionEpoch,serverState,sid.它和Notification相互对应.为了区别,用了2个几乎完全一样的类.
3. FastLeaderElection类持有2个队列,sendqueue和recvqueue.sendqueue是当前server亟待发给其他server的消息(ToSend),recvqueue是当前server已经接收但还没有处理的消息(Notification).
4. SendWorker和RecvWorker在socket建立成功后,同时被创建,实例化时同时也持有sid,dataInput或dataoutput引用,很便捷的操作socket数据.
5. FastLeaderElection也不能脱俗,使用2个队列分别保存亟待发送的ToSend和Nofification,数据结构为LinkedBlockingQueue.
6. QuromCnxManager持有3个数据结构,:

• queuesendMap,亟待发送的消息,key为sid,value为一个ArrayBlockingQueue,即每个sid对应socket维护一个队列,有各自的socket负责发送;
• senderWorkerMap,key为sid,value为SendWorker实例,已标记server是否和sid已经建立了链接,如果此sid下的SendWorker不为null,则标示链接已经建立.
• recvQueue,一个ArrayBlockingQueue,标示server在选举端口上接收到的”提议”消息,此队列最终将交付给FastLeaderElection类来消费.
• FastLeaderElection也不能脱俗,使用2个队列分别保存亟待发送的ToSend和Nofification,数据结构为LinkedBlockingQueue.

  F3.FastLeaderElection选举过程

  选举过程中,有几个参数容易混淆: logicalclock,这个匪夷所思的命名,意思是当前server所持有的最高选举轮数,确保自己所接受的其他server提议都处于同一轮选举上(计算投票结果才有效);Notification中有一个electionEpoch变量,标示提议者发送消息是所处于的选举轮数.a) 为了保证选举结果的有效性,所有的投票epoch必须一致,消息中较低的epoch将会被抛弃;而且server从消息中发现更高的epoch,也会将本地的logicalclock和它保持一致,并清除先前的投票集合,重新计数.b) 如果接受的”提议”消息的epoch,比本地的logicalclock要小,那么当前server会立即反馈一个ToSend,告知提议者,最新的epoch(logicalclock).当前server已经计算出了leader,并且处于Following或者Leading状态,如果接收到的提议消息是Looking,那么次消息就是滞后的投票,或者是提议者加入集群,寻找Leader. Observer发送的投票是直接被忽略,而且server也不会向Observer发送”提议”.

  ?

  
  ?F4.选举过程

  当server接受到的”提议”消息中,epoch大于或者等于当前server本地的logicalclock时,server会对此”提议”进行校验,如果检验成功,将会将本地持有的提议信息替换.[注意,此处为server之间信息比较,而非比较”投票”信息],依次比较epoch,zxid,sid.

   a) 如果proposalEpoch > peerEpoch,校验成功.此时的peerEpoch是整个集群server最近一次投票成功时的epoch;每次投票成功,每个server就会把epoch写入到文件.否则,参见b) b) 如果proposalEpoch = peerEpoch,并且proposalZxid > currentZxid,校验成功.currentZxid为当前server的zkDatabase中持有的最大的zxid.否则,参见c) c) 如果proposalZxid = currentZxid,并且”提议者”的sid比当前server的sid大,校验成功.否则失败.最终将由sid来决定,是否接受此次”提议”.    Server本地保持者一份当前投票的最新(高)的提议副本,此副本包括epoch/zxid/leader(sid);如果server从消息中发现有更好的提议,将会替换本地的这些信息.并在适当的时机,将自己收集到的提议副本发送给其他”提议者”.知道最终达成一致.

  ?如果”提议”被当前server校验通过,将被封装成一个更加简小的对象Vote(投票).”投票”将会被放入一个Map中,key为sid,value就是”投票”,确保每个server都参与而且只有一个有效的vote.“断言是否成功”:截止到目前,当前”提议”是否已经是”多数派”,如果是,即可结束投票,leader已经在集群中产生.(可以提前确定leader). Outofelection是个map,key为sid,value为vote(投票);它的本意是存储那些在非投票期间所产生的”vote”(类似于票据),在失效的server重新加入集群,将会触发”选举”,此时其他server的”提议”将会被加入到outofelection,当前server根据此map来判断是否存在”多数派”,如果集群处于”危险期”(少数派),那么新加入的server选举直到”多数派”出现.新server加入,投票时还会进行CheckLeader操作.

  if (termPredicate(outofelection, new Vote(n.leader,n.zxid, n.electionEpoch, n.peerEpoch, n.state))                                && checkLeader(outofelection, n.leader, n.electionEpoch)) {synchronized(this){logicalclock = n.electionEpoch;self.setPeerState((n.leader == self.getId()) ?ServerState.LEADING: learningState());}Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);leaveInstance(endVote);return endVote;}

  ?
  

  [引导:Leader选举补充部分]

  ?

  Leader: ?Cluster环境中操作"调度者",负责"数据一致性"的控制,主要包括"write操作"/Session过期控制等.

  Follower: "跟随者",它是和Leader共同构成Cluster多数派,直接负责接收Client的read和write操作,并转发write操作给"Leader".

  Observer(“围观者”):

  在ZK server中，有一种特殊的server类型，是Observer(read-only),它可以在不影响写入性能的同时扩展zk。zk之所以设计这种类型的server，是可以理解的；如果一个cluster中不断新增的voting member（follower），将会导致write性能下降，这归因于write操作需要至少半数的follower同意才能被执行，所以这种“提议/投票”的开支会随着“follower”的增加而增加。

  我们引入了一个新的server类型，就是Observer；它对于解决这种问题很有帮助，而且跟一步提高了ZK的扩展性。Observer为non-voting成员,即不参与leader选举和其他操作的“提议”，它就像一个“围观者”一样只会接受投票的结果，而不是投票的协议。除了这个简单的区别之外，它和follower几乎一样。client也可以和它们建立链接，发送read和write请求。Observer和Follower一样把write请求转发给leader，只是它们然后就是简单的等待（hear）此操作的投票结果；因此我们能够在无损性能的情况下增加数个observer。

  Observer还有其他的优点，因为它们不参与投票，他们不是ZK成员的核心部分；所以即使它们失效了，或者离群了，也不会对ZK 服务带来任何不利影响。Observer可以链接比followers更加不可靠的网路。

  Observer类中可以看到它对各种消息的处理，Observer不是ZAB的一部分，也参与提议，在processPacket()方法中可见，observer会忽略PROPOSAL/COMMIT类型的请求，而增加了一个INFORM，这个请求类型是为Observer设计的，当proposal成功执行后，会把数据packet以INFORM消息类型发给Observer（Follower不关系此类型），那么observer即可以在本地应用最新的数据。

  ?

  设置Observer非常简单，只需要将zoo.cfg中peerType=observer即可。

  简单的使用场景：

  作为数据中心桥：如果构成ZK环境有2个数据中心，那么2个数据中心的网络延迟是一个很棘手的问题，（延迟）可能会导致“假故障”问题（超时等）。不过可以将其中一个datacenter全部设置为observer，这样可以避免这些问题，而且链接observer的客户端仍然可以看到问题提议（issue proposal）。（zk cluster中一部分机器作为observer，这部分及其可能位于位置较远的其他地区，为了不让这种“位置”距离影响了zk服务，只能这这部分zk server成为observer，比如你的zk服务一部分在中国，另部分可能位于美国机房）。

  ?

  ?

  ?