zookeeper学习记录(二)

背景

继上一篇的zookeeper的学习,上一篇主要偏向于zookeeper的总体结构的熟悉和使用层面。 本文主要是记录自己学习其内部的选举算法,一致性处理策略。

过程

在开始之前,推荐几篇比较不错的文章:

zookeeper server

入口:org.apache.zookeeper.server.quorum.QuorumPeerMain

  • 通过QuorumPeerConfig读取zoo.cfg配置文件,myid信息等。 具体的参数可以参考官方文档: http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html
    主要关注几个参数:
    peerType=observer/participant  (是否是观察者,或者参与Leader/Follower)
    electionAlg=0/1/2/3/ (选举算法)
    
    server.1=zoo1:2888:3888
    server.2=zoo2:2888:3888
    server.3=zoo3:2888:3888
    
    group.1=1:2:3  (机器分组)
    group.2=4:5:6
    group.3=7:8:9
       
    weight.1=1  (某机器权重)
    weight.2=1
    weight.3=1 
  • 创建QuorumPeer,启动服务。
QuorumPeer:
  • 首先加载本地的zkDatabase
  • startLeaderElection,发起一次Leader选举。 选举算法:LeaderElection /  FastLeaderElection / AuthFastLeaderElection
  • 确定自己的角色后,进行响应的角色初始化:
    OBSERVING :  observer.observeLeader();
    FOLLOWING :  follower.followLeader();
    LEADING :  leader.lead();

LeaderElection算法:

  1. 每个机器节点加入,都发起一次Vote。
  2. zookeeper server节点接受到新一轮的Vote,都返回上一轮的Leader选举的最后Vote结果。如果处于LOOKING,比如第一次加入的机器,则Vote自己
  3. 发起Vote的机器,收集完所有server的Vote结果(包括自己),统计一下结果,并且判断一下是否超过半数
    if (result.winningCount > (self.getVotingView().size() / 2))
     注意:这里的>号,所以如果单台机器启动,无法通过给自己Vote,使自己成为Leader。一定要>=2台机器的参与
  4. 如果没有超过半数,则记录一下本次的投票结果。下一次Vote时,就直接投给上一轮票数最高的Vote,继续进入步骤3
说明: myid序号大的在Vote选举时比较有优势,同样的票数winner会是myid最大的server,从而保证每次的Vote必然会产生一个唯一的winner。

FastLeaderElection算法:
  1. 每个机器节点加入,都向外部建议自己做为Leader。
  2. zookeeper server接受到请求后,进行一个抉择: 
    if ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))
     判断当前的zxid和myid是否大于当前Vote,如果是则更新之,并同样广播给所有的server。
    注意:
         Notification中有个epoch标志,表明当前发起的Vote的传递的次数。比如A发给B,B更新了自己的Vote后,再发给C。这时发的通知中epoch=2。
         有点类似图论里的概念,如果notice.epoch < 当前最后一次更新Vote的epoch,则不做任何处理。一个逐步收敛的有向环图
  3. 单个机器上收到了其他所有机器的Vote结果后,判断出最后的winner结果

Leader处理:
  • 启动LearnerCnxAcceptor,监听Follower的请求。针对每个链接的Follower,开启一个新线程LearnerHandler进行处理
  • 然后针对所有的LearnerHandler,while(true)进行心跳检查ping。针对每次ping结果,针对有ack响应的结果进行vote统计,如果发现超过半数失败,则退出当前的Leader模式,这样又是发起新一轮的选举
Follower处理:
  • 建立socket,链接到Leader server上
  • 发起一次syncWithLeader同步请求,此时Leader会根据当前的最大的zxid对比客户端的zxid,发送DIFF/TRUNC/SNAP指令给follower上,保证follower和leader之间的数据一致性。
  • 同步完成后,就进入while(true){read , process}的工作模式,开始接受Leader的指令并处理
    PING :  响应Ack
    PROPOSAL :  记录到自己的缓冲队列pendingTxns中,等待sync指令后刷新到zkDataBase中。有点类似2PC阶段事务
    COMMIT :  刷新pendingTxns中的对应记录
    SYNC : 客户端的同步request请求
Observer处理:
  • 建立socket,链接到Leader server上
  • 发起一次syncWithLeader同步请求
  • 同步完成后,进入while(true){read , process}的工作模式,和Follower有点不同,主要在于其不处理PROPOSAL/COMMIT等2PC阶段。只接受INFORM,Leader告诉最终的更新结果,Observer直接提交到zkDataBase中。

针对Leader/Follower/Observer都有对应的ZooKeeperServer提供客户端的处理,分别是:LeaderZooKeeperServer / FollowerZooKeeperServer / ObserverZooKeeperServer 。
下面继续来看一下对应的Server处理,主要区别在于RequestProcessors的组织上。

LeaderZooKeeperServer处理:
  • PrepRequestProcessor -> ProposalRequestProcessor -> CommitProcessor -> toBeAppliedProcessor -> FinalRequestProcessor处理顺序
  • PrepRequestProcessor主要处理ACL控制,不细讲,自己看看代码就懂的
  • ProposalRequestProcessor,处理有点特殊。因为Leader server同样会提供客户端API的create操作,所以需要做特殊处理
    1. 如果请求是LearnerSyncRequest,表明是leader做为server提供给客户端服务,并且接受到客户端的sync请求。
    2. 否则认为是需要进行决策,发给所有的follower进行投票。(这里的请求可能来自于follower的写动作请求leader决策,也可能是leader做为server自己接收到的请求),通过AckRequestProcessor先给自己投票。
    注意: ProposalRequestProcessor只会针对create/delete等写操作会发起一次Vote。 读操作会直接交由后续的Processor进行处理
  • CommitProcessor主要是一些等待commit处理的request,接收到sync指令后就会提交到下一个Processor进行处理。
    做为leader,会在收集足够的Vote后,自己会给自己发送一次sync指令
    做为Follower,会受到Leader发送的Sync指令,然后自己提交commit动作
  • toBeAppliedProcessor: 主要的作用就是记录当前正在提交到zkDatabase中的request数据,保证新的Follower连接上来时,能获取到这些处于内存中"正准备提交"的数据
  • FinalRequestProcessor : 处理最后的请求,比如读/写请求,此时所有的server都会同步的写入数据。

FollowerZooKeeperServer处理:
  • 接受客户端请求: FollowerRequestProcessor -> CommitProcessor -> FinalRequestProcessor
    1. 客户端接受请求后,针对一些写动作(比如create,delete,setData,setAcl等),FollowerRequestProcessor会发起一个request,请求leader进行所有server的一致性的控制。 同时会将request请求递交到commitProcessor
    2. CommitProcessor请求,会等待leader的sync request请求,会提取出相对应的request,提交到下一个processor进行处理。
    3. FinalRequestProcessor,处理最终的指令请求。因为一些写动作通过follower->leader的交互已经得到Leader的ack,会保证每个节点都能写入request数据。
  • 处理Leader的PROPOSAL/COMMIT: SyncRequestProcessor -> SendAckRequestProcessor。 (主要是接受Leader广播的其他server的数据变更事件,保证所有server都能得到同步更新)
    1. 主要是接受到Leader的PROPOSAL request后,先将request暂存于pendingTxns,并提交到SyncRequestProcessor的queue队列,排队进行后续发送Ack给Leader处理
    2. 接受到Leader端的sync/commit指令,将pending的request请求提交到当前server的zkDataBase中。 
ObserverZooKeeperServer处理: 
  • 接受断乎端请求: ObserverRequestProcessor -> CommitProcessor -> FinalRequestProcessor
ObserverZooKeeperServer处理和FollowerZooKeeperServer基本类似,只不过它不会处理Leader的PROPOSAL/COMMIT事件,也就是不会参与Vote处理。

哈哈,图画起来挺累人的,这里盗用了taobao同学画的图,原文可参考前面推荐的图。
Leader处理:

zookeeper学习记录(二)_第1张图片
 
Follower处理:

zookeeper学习记录(二)_第2张图片
 
Leader/Follower之间的消息传递:

zookeeper学习记录(二)_第3张图片
 

最后

感慨几下:

1. 彪悍的图,画的比较精细,不是真正了解Follower/Leader之间的数据处理,不太容易看的懂

2. zookeeper开发者仅仅通过Tree树状结构,可以实现分布式一致性控制,可以衍生出Barrier,Lock等功能。感叹人的智慧

3. 感叹淘宝的同学,发觉在rdc.taobao.com/上有n多人研究分布式的相关内容,而且文章质量都不错。为啥同样是阿里的子公司,学习的氛围咋就差这么多呢,可能一个原因还是数据量的问题。


你可能感兴趣的:(zookeeper)