Zookeeper实现分析一

原创
2013/12/22 08:40
阅读数 6.5K

<h4>最近准备面试,把一年多前阅读zookeeper代码时写的阅读笔记翻出来,顺便整理一下发成博客。</h4> <p></p> <h4>--------------------------------------------------------------------------------------</h4> <h4>1 Zookeeper介绍</h4> <p>Zookeeper是一个分布式的协调服务,为分布式应用程序提供synchronization、configuration maintenance、groups和nameing服务。</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084037_qU1P.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="wps_clip_image-1862" border="0" alt="wps_clip_image-1862" src="http://static.oschina.net/uploads/img/201312/22084037_UcOG.png" width="519" height="163" /></a></p> <p>Zookeeper是一个有众多服务器节点组成的集群,这些节点中有一个主节点(leader),leader是通过leader selection自动地从服务器节点中选举出来。Zookeeper提供了一个类似于标准文件系统目录结构的hierarchal namespace(层次化的命名空间)。如下图所示,hierarchal namespace中的每一个节点都被称为 znode。Znode是组成hierarchal namespace的基本单位。在源码中对应于类DataNode,其维护着节点用户数据、父节点和子节点集合,以及本节点状态。用户可以在hierarchal namespace中创建znode,将数据保存在znode中,并监听znode的状态变化,Zookeeper会保证client对znode的操作是顺序一致性。</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084037_J36w.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="wps_clip_image-28286" border="0" alt="wps_clip_image-28286" src="http://static.oschina.net/uploads/img/201312/22084037_RZUj.png" width="382" height="220" /></a></p> <h4>2 Zookeeper实现分析</h4> <p>Zookeeper服务器节点的实现可以分成两部分:一部分是处理与客户端交互,实现客户端对zookeeper的hierachal namespace的各种操作。另一部分是作为zab算法(paxos算法的zookeeper实现)的参与者(leader、follower、observer三种角色的其中一种),实现具体的算法逻辑。</p> <p>在这篇博客里,我们只讨论zookeeper服务器如何实现第一个部分功能。</p> <p>Zookeeper服务器的hierachal namespace、znode、客户端与服务器连接、以及客户端可以监听服务器的znode状态的watch机制之间的元数据关系如下图所示:</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084038_XTG7.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084038_5tqz.png" width="554" height="404" /></a> </p> <p>Zookeeper使用<a href="http://baike.baidu.com/view/1436495.htm">Trie树</a> 来实现了hierachal namespace,由PathTrie这个类来完成。为了实现从路径到znode的映射,zookeeper在内存中维护了一个znode的hashmap,key为znode在hierachal namespace上的路径,value为znode对象,znode在zookeeper源码中由DataNode这个类实现。为了实现client监听znode的状态变化,zookeeper将与客户端的连接和hierachal namespace的节点路径进行映射,WatchManager这个类就是用于维护这个映射关系的,其中NIOServerCnxn是zookeeper服务器与client的一个socket连接;为了监听Znode的目录结构的变化和数据变化,zookeeper使用了两个WatchManager,分别用来监听namespace的目录结构和数据的变化。</p> <p>所有以上这些关系都封装在DateTree这个类中,DateTree的类图如下所示。</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084038_o0nR.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084039_FRC3.png" width="499" height="543" /></a> </p> <p>在paxos算法中有三种角色,分别是提案者,接受者和学习者。在zookeeper中有三种类型的节点,分别是leader、follower和observer三种类型的节点,分别与paxos的三种角色相对应;需要注意的是zookeeper中还有一个learner的概念,这个learner是paxos中的学习者,leader、follower和observer都是learner(即都是学习者,可以学习提案),但observer节点除了是learner之外没有其他功能,也就是说observer只能学习已经批准的提案,而不会参与到提案的投票过程中。observer这个角色的设定是为了保证提案选举的性能不会随着zookeeper集群规模扩大而降低(参与投票的节点越多,每一次投票花费的事件就越多)。</p> <p>在zookeeper中用LeaderZooKeeperServer,FollowerZooKeeperServer和</p> <p>ObserverZooKeeperServer这三个类来实现三种类型的服务器节点。类图如下所示,为了简单起见没有详细给出成员变量和成员函数。</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084039_xoOy.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084039_DNAq.png" width="348" height="401" /></a> </p> <p>由于Zookeeper的服务器节点有多种类型,不同类型的服务器节点对client发过来的信令都有不同的处理流程,为了实现最大程度上的代码复用,zookeeper采用了责任链的设计模式来实现各种类型的zookeeper节点。所以在每一个ZookeeperServer上都会维护一个RequestProcessor责任链,来处理各个节点上的逻辑。</p> <h5>2.1 leaderZookeeperServer</h5> <p>Leader要完成以下几个事情:</p> <p>1、接收客户端的request请求</p> <p>2、将会修改同步数据的request请求 转化为proposal,并保存.</p> <p>3、向所有的follower发送proposal。</p> <p>4、接收follower的ack。</p> <p>5、统计收到的ack,如果某一个proposal的ack超过了半数,那么向所有follower发送commit 信令,并向所有observer发送inform信令,执行这个proposal的动作。</p> <p>6、leader自己执行已经被commit的proposal所对应的操作,并回复结果。</p> <p>LeaderZookeeperServer的责任链如下面两图所示:</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084039_ZjgO.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084039_3Go0.png" width="411" height="354" /></a> </p> <p><a href="http://static.oschina.net/uploads/img/201312/22084040_03MO.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084040_tHAf.png" width="515" height="554" /></a> </p> <h5>2.2 FollowerZooKeeperServer</h5> <p>Follower:主要负责批准或否决leader提出的proposal。Follower的主要逻辑处理如下:</p> <p>1、 发现leader。</p> <p>2、 建立与leader的连接。</p> <p>3、 向leader注册。(leader activation)</p> <p>4、 与leader进行同步。</p> <p>5、 无限循环</p> <p>---读取从leader处接收到的信令。</p> <p>---处理从leader处接收到的信令。</p> <p>A、 如果是PROPOSAL信令(写请求),将此信令投递到FollowerZooKeeperServer的synProcessor。主要作用是回复leader一个ack。</p> <p>B、 如果是COMMIT信令,将此信令投递到FollowerZooKeeperServer的commitProcessor。最终执行FollowerZooKeeperServer的commit函数。</p> <p>C、 如果是SYNC信令,将此信令投递到FollowerZooKeeperServer的commitProcessor。commitProcessor直接将此信令转发给FinalRequestProcessor,将sync信令带的内容写入持久层。</p> <p>FollowZookeeperServer的责任链如下所示:</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084040_aXKr.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084040_frJf.png" width="429" height="259" /></a> </p> <p><a href="http://static.oschina.net/uploads/img/201312/22084040_jmip.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084041_zn2Z.png" width="509" height="598" /></a> </p> <h5>2.3 ObserverZooKeeperServer</h5> <p>observer:学习已经被commit的proposal的结果,然后执行相应的操作。Observer主要处理逻辑:</p> <p>1、 发现leader。</p> <p>2、 连接到leader上,建立TCP连接。</p> <p>3、 与leader进行同步,同步leader上已经被commit的proposal。</p> <p>4、 无限循环,读取接收到得信令,处理信令。</p> <p>1、如果是syn信令,调用<a name="OLE_LINK1"></a><a name="OLE_LINK2">ObserverZooKeeperServer</a>的syn函数,投递到commitProcessor中。</p> <p>2、如果是info信令,同样调用ObserverZooKeeperServer的commit函数,投递到commitProcessor中。</p> <p>OserverZookeeperServer的责任链基本上与follower的相同如下,只是commitProcessor调用的commit函数里的处理不同:</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084041_UJ6J.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084041_crkg.png" width="393" height="239" /></a> </p> <p><a href="http://static.oschina.net/uploads/img/201312/22084041_u81T.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084041_35zj.png" width="510" height="591" /></a> </p> <h5>2.4 Zookeeper各节点交互</h5> <p>Zookeeper各个角色的信令交互图:</p> <p>最后画了一张各个zookeeper server的信令交互图</p> <p><a href="http://static.oschina.net/uploads/img/201312/22084042_v6Vr.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/22084042_tGiP.png" width="529" height="336" /></a> </p> <p>作者zy,QQ105789990</p>

展开阅读全文
打赏
1
17 收藏
分享
加载中
更多评论
打赏
0 评论
17 收藏
1
分享
在线直播报名
返回顶部
顶部