一种云平台下可扩展的分布式协调服务管理方法
【专利摘要】本发明公开了一种云平台下可扩展的分布式协调服务管理方法，包括：以中间节点交叉树林的组织方式对分布式集群的所有节点进行初始化，所有成员节点根据来自中心管理节点的全局网络拓扑结构查询出本节点的父子成员节点信息，所有父子成员节点之间以心跳机制进行信息同步和通信，成员节点判断是否从其它成员节点接收到成员状态变更信息，如果接收到则进一步判断该成员状态变更信息指示成员减少还是增加，如果是减少则成员节点如果收到成员减少的成员状态变更信息后，根据中断心跳封装出一个成员状态变更信息，并将其发送到中心管理节点。本发明更新服务的效率不会在扩展过程中急剧下降，因此更适合大规模的云平台和数据处理系统。
【专利说明】一种云平台下可扩展的分布式协调服务管理方法
【技术领域】
[0001]本发明属于云计算【技术领域】，更具体地，涉及一种云平台下可扩展的分布式协调服务管理方法。
【背景技术】
[0002]云计算和大数据盛行的今天，云服务和数据处理分析通常建立在万级甚至百万级规模的机器平台上。在如此规模的集群中，节点失效、磁盘错误甚至网络失效等问题出现概率较高，这给服务容错和可靠性提出了很大的挑战，对此通常采用协调服务来解决问题。协调服务系统是在不改变原有系统架构下解决容错的问题、保证可靠服务的最佳解决方案，通过可靠的协调服务来实现集群的可靠管理、分布式算法以及事件通知等机制。在现有的协调服务系统中，Google实现了锁服务系统Chubby,用于为诸如BigTable、Percolator>GFS的分布式系统提供诸如元数据管理、命名服务、失效监控等可靠服务；Yahoo !开发的开源协调服务系统Zookeeper，通过异步原语的接口实现诸如分布式队列、分布式锁、订阅发布模型等可靠的服务。其中，Zookeeper是Chubby —个开源的实现,它是一个针对大型分布式系统的可靠协调系统，提供诸如配置维护、名字服务、分布式同步、组服务的协调服务。其设计目标是封装复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。其以快速Paxos算法为基础同时采用多个服务器同时服务，中心管理节点协调内部一致性，从而解决了 Chubby的单点瓶颈问题。
[0003]但是随着云技术处理场景的多样化以及云平台规模的不断扩大，云平台对协调服务的要求越来越高，需求也越来越多。而现有的分布式协调服务系统大都采用中心化的架构来协调数据的一致性，中心管理节点所承担的工作比其他节点要多，当协调服务增多时，中心节点比其他节点更容易达到瓶颈，导致整个一致性过程性能下降，其更新性能也会随着系统的扩展下降。另外，这种中`心化协调方式会因为中心节点的失效而出现短暂的服务中断，服务失效的恢复时间会随着节点的增多而变长，存在扩展过程中可靠性和可用性问题。
[0004]由此可见，协调服务的动态扩展在大规模云平台扮演非常大的作用，但也是传统协调服务系统尚未解决的问题。云计算发展至今，云平台的规模不断的扩大，协调服务的要求不断增多，因此能否根据当前系统的规模和负载来动态调整协调服务系统的规模是非常有价值的事情，也是一件很有挑战的研究内容。因此，如何实现可动态扩展的、高性能的和高可靠的协调服务是当今云平台下协调服务系统急需解决的首要问题。
【发明内容】
[0005]针对现有技术的以上缺陷或改进需求，本发明提供了一种云平台下可扩展的分布式协调服务管理方法，其目的在于，解决现有协调服务系统中存在的扩展性差和管理过程效率低下的技术问题。
[0006]为实现上述目的，按照本发明的一个方面，提供了一种云平台下可扩展的分布式协调服务管理方法，包括以下步骤:
[0007]( I)以中间节点交叉树林的组织方式对分布式集群的所有节点进行初始化；
[0008](2)所有成员节点根据来自中心管理节点的全局网络拓扑结构查询出本节点的父子成员节点信息，所有父子成员节点之间以心跳机制进行信息同步和通信；
[0009](3)成员节点判断是否从其它成员节点接收到成员状态变更信息，如果接收到则进一步判断该成员状态变更信息指示成员减少还是增加，如果是减少则转入步骤(4)，如果是增加则转入步骤(7)，如果没有接收到则持续监听来自其它成员节点的成员状态变更信息；
[0010](4)成员节点判断是否接收到来自父节点或子节点的心跳信息，如果接收到则根据心跳信息封装出一个成员状态变更信息，并将其发送到中心管理节点，然后转入步骤(5)，否则该成员节点继续监听来自父节点或子节点的心跳信息；
[0011](5)中心管理节点判断来自成员节点的成员状态变更信息是否正确，如果正确则更新全局网络拓扑结构，并将更新后的全局网络拓扑结构发送到所有的根成员节点，再由根成员节点分发给它的子孙成员节点，然后转入步骤(6)，否则等待接收来自其他成员节点的成员状态变更信息；
[0012](6)所有成员节点根据更新后的全局网络拓扑图更新其本地的网络拓扑结构；
[0013](7)成员节点根据成员状态变更信息判断是否有新的成员节点请求获取全局网络拓扑结构，若是则向中心管理节点发送报告信息，以请求中心管理节点为该新的成员节点分配颜色信息，然后转入步骤(8)，否则成员节点继续监听是否有成员状态变更信息；
[0014](8)中心管理节点根据报告信息为该新成员节点分配颜色信息，并更新其自身的全局网络拓扑结构，并将新后的全局网络拓扑结构发送到新的成员节点，转入步骤(9)，同时也将更新后的全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它所有的子孙成员节点，转入步骤(6)；
[0015](9)新的成员节点根据来自中心管理节点的更新后的全局网络拓扑结构更新其本地的网络拓扑结构，并根据更新后的网络拓扑结构查询其父子成员节点信息，并与其父子成员节点建立心跳联系。
[0016]优选地，步骤(I)具体包括以下子步骤:
[0017](1-1)分布式集群中的中心管理节点接收管理员对分布式集群所有节点的命名nodel, node2,..., noden,其中η为分布式集群中节点的总数,并将该命名信息同步到所有节点；
[0018](1-2)中心管理节点对分布式集群的颜色集、最大树数和最大子节点数进行配置，并将配置结果作为限制参数转发给所有成员节点，用于对整个分布式集群的拓扑结构进行限定；
[0019](1-3)中心管理节点在分布式集群启动后将颜色集分配给所有节点，然后根据每个节点的颜色、IP地址以及步骤(1-2)中配置的最大树数和最大子节点数构建由多棵树组成的全局网络拓扑图，如图1所示；
[0020](1-4)中心管理节点为全局网络拓扑结构设定版本格式、初始版本号以及递增方式，并将该全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它的子孙成员节点；[0021]优选地，编号为nodel的节点即为中心管理节点，其它节点为成员节点。
[0022]优选地，步骤(1-3)中全局网络拓扑的构建过程遵循以下原则:
[0023]( 1-3-1)相同颜色的节点集中在一棵树的根节点或中间节点，且分散在其它树的叶子节点中；
[0024](1-3-2)—个节点可以同时出现在多棵树中，但每个节点只能在一棵树中充当根节点或者中间节点；
[0025](1-3-3 )新节点应该插入到与之同颜色的树中最靠近根节点的节点中，且该节点中子节点的数目未超过最大子节点数；
[0026](1-3-4) 一个节点的子节点数目达到最大子节点数时,新插入的节点应该插入到该节点的子树中，并且被插入的子树是所有子树中高度最矮或者子孙节点数目最少的；
[0027](1-3-5)当全局网络拓扑结构中树的总数达到最大树数时，如果再有新节点加入分布式集群，则不为该新节点创建新的树结构，而是将该新节点插入已有的树结构中。
[0028]优选地，步骤(3)中，成员节点与其他某个成员节点的心跳机制突然中断时，表明该成员节点收到了成员减少的成员状态变更信息，成员节点收到了它所维护的全局网络拓扑结构中不存在的新的成员节点的心跳信息时，表明该成员节点收到了成员增加的成员状态变更信息。
[0029]优选地，步骤(5)中，如果中心管理节点同时接收到来自一个以上成员节点的成员状态变更信息，则表示成员状态变更信息是正确的，如果仅接收到来自一个成员节点的成员状态变更信息，则表示成员状态变更信息是错误的。
[0030]总体而言，通过本发明所构思的以上技术方案与现有技术相比，能够取得下列有益效果:
[0031]1、扩展性好:本发明由于采用了步骤(I)中的成员组织方式和步骤(3)中对成员节点变更的自动监听机制，使得分布式协调服务系统在有新的成员加入和旧成员移出时能实时动态的捕捉到这一变化并做出相应的调整。因此，实现了分布式协调服务系统的动态扩展。
[0032]2、可靠性:由于采用了步骤(I)中的成员组织方式以及以版本号命名的网络拓扑结构，简化了整个协调服务系统的信息同步的过程。该种成员组织方式中节点的交叉冗余特性，使得数据的分发也是冗余的，所以当有节点失效时，也能将数据准确可靠地同步到所有成员节点。
[0033]3、高效性:步骤(I)和步骤(5)中，所有数据的同步以及全局网络拓扑结构的分发都是由中心管理节点首先分发给每棵树的根节点，再由根节点分发给它的子孙节点，将中心管理节点的负载分层次的分担给每棵树的根节点，避免了中心管理节点因负载过大性能性能瓶颈。
[0034]4最优性:步骤(I)中，在中心管理节点上对全局网络拓扑结构中对树的数量以及节点的最大子节点数进行限制，从而控制的树的高度和维度，保证了每棵树的负载均衡，提高协调服务系统的整体性能。
【专利附图】
【附图说明】
[0035]图1是本发明中间节点交叉树林的结构示意图。[0036]图2是本发明云平台下可扩展的分布式协调服务管理方法的流程图。
【具体实施方式】
[0037]为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
[0038]本发明的整体思路在于，对协调服务系统的成员采用中间节点交叉树林的组织方式，同时在对协调服务系统网络拓扑结构的构建过程中，对树的高度和维度进行限定，保证了系统整体的负载均衡。在系统的管理过程中，父子节点间的心跳监听机制能使得协调服务系统实时动态的感知到系统成员节点的变化，从而实现协调服务系统的动态扩展。数据分发和同步过程的冗余分发保证了系统可靠性。
[0039]本发明云平台下可扩展的分布式协调服务管理方法包括以下步骤:
[0040](I)以中间节点交叉树林的组织方式对分布式集群的所有节点进行初始化，具体包括以下子步骤:
[0041](1-1)分布式集群中的中心管理节点接收管理员对分布式集群所有节点的命名nodel, node2,..., noden,其中η为分布式集群中节点的总数，并将该命名信息同步到所有节点；具体而言，默认情况下编号为nodel的节点即为中心管理节点，其它节点为成员节
占.[0042](1-2 )中心管理节点对分布式集群的颜色集(Co I or_Set)、最大树数(Max_Co I or_Num)和最大子节点数(Max_Children_Size)进行配置，并将配置结果作为限制参数转发给所有成员节点，用于对整个分布式集群的拓扑结构进行限定；具体而言，颜色集、最大树数和最大子节点数是由分布式集群的规模决定；
[0043](1-3)中心管理节点在分布式集群启动后将颜色集分配给所有节点，然后根据每个节点的颜色、IP地址以及步骤(1-2)中配置的最大树数和最大子节点数构建由多棵树组成的全局网络拓扑图，如图1所示；具体而言，全局网络拓扑的构建过程遵循以下原则:
[0044](1-3-1)相同颜色的节点集中在一棵树的根节点或中间节点，且分散在其它树的叶子节点中；
[0045](1-3-2)—个节点可以同时出现在多棵树中，但每个节点只能在一棵树中充当根节点或者中间节点；
[0046]( 1-3-3 )新节点应该插入到与之同颜色的树中最靠近根节点的节点中，且该节点中子节点的数目未超过最大子节点数；
[0047](1-3-4) 一个节点的子节点数目达到最大子节点数时,新插入的节点应该插入到该节点的子树中，并且被插入的子树是所有子树中高度最矮或者子孙节点数目最少的；
[0048](1-3-5)当全局网络拓扑结构中树的总数达到最大树数时，如果再有新节点加入分布式集群，则不为该新节点创建新的树结构，而是将该新节点插入已有的树结构中；
[0049](1-4)中心管理节点为全局网络拓扑结构设定版本格式、初始版本号以及递增方式，并将该全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它的子孙成员节点；[0050]步骤(I)的优点在于，避免了中心化组织方式易形成的瓶颈问题，同时通过参数限制可以保证每棵树的高度及节点数目近似一致，也就保证了每颗树的负载是近似均衡的，且每棵树中的事务处理时间是相似的，从而保证了全局数据提交的效率。
[0051](2)所有成员节点根据来自中心管理节点的全局网络拓扑结构查询出本节点的父子成员节点信息，所有父子成员节点之间以心跳机制进行信息同步和通信；
[0052](3)成员节点判断是否从其它成员节点接收到成员状态变更信息，如果接收到则进一步判断该成员状态变更信息指示成员减少还是增加，如果是减少则转入步骤(4)，如果是增加则转入步骤(7)，如果没有接收到则持续监听来自其它成员节点的成员状态变更信息；具体而言，成员节点与其他某个成员节点的心跳机制突然中断表明该成员节点收到了成员减少的成员状态变更信息，成员节点收到了它所维护的全局网络拓扑结构中不存在的新的成员节点的心跳信息时表明该成员节点收到了成员增加的成员状态变更信息。
[0053](4)成员节点判断是否接收到来自父节点或子节点的心跳信息(即在拓扑结构中，其父节点或者子节点在指定的时间内通过心跳机制报告其生命存活状态)，如果接收到则根据心跳信息封装出一个成员状态变更信息，并将其发送到中心管理节点，然后转入步骤
(5)，否则该成员节点继续监听来自父节点或子节点的心跳信息；
[0054](5)中心管理节点判断来自成员节点的成员状态变更信息是否正确，如果正确则更新全局网络拓扑结构，并将更新后的全局网络拓扑结构发送到所有的根成员节点，再由根成员节点分发给它的子孙成员节点，然后转入步骤(6)，否则等待接收来自其他成员节点的成员状态变更信息；具体而言，如果中心管理节点同时接收到来自一个以上成员节点的成员状态变更信息，则表示成员状态变更信息是正确的，如果仅接收到来自一个成员节点的成员状态变更信息，则表示成员状态变更信息是错误的；
[0055]步骤(5)的优点在于，中心管理节点可以根据接收到的成员状态变更信息的条数来判断这个成员状态变更信息是由于网络状况不佳造成的还是真的有成员节点变更，从而保证的系统扩展过程中的正确性和可靠性。
[0056](6)所有成员节点根据更新后的全局网络拓扑图更新其本地的网络拓扑结构；
[0057](7)成员节点根据成员状态变更信息判断是否有新的成员节点请求获取全局网络拓扑结构，若是则向中心管理节点发送报告信息，以请求中心管理节点为该新的成员节点分配颜色信息，然后转入步骤(8)，否则成员节点继续监听是否有成员状态变更信息；
[0058](8)中心管理节点根据报告信息为该新成员节点分配颜色信息，并更新其自身的全局网络拓扑结构，并将新后的全局网络拓扑结构发送到新的成员节点，转入步骤(9)，同时也将更新后的全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它所有的子孙成员节点，转入步骤(6)；
[0059]步骤(8)的优点在于，在全局网络拓扑结构发生更新后，对于更新的全局网络拓扑结构的分发采用分层的分发机制，可以降低中心管理节点的负载，降低延迟，提高系统的效率。
[0060](9)新的成员节点根据来自中心管理节点的更新后的全局网络拓扑结构更新其本地的网络拓扑结构，并根据更新后的网络拓扑结构查询其父子成员节点信息，并与其父子成员节点建立心跳联系。
[0061]本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
【权利要求】
1.一种云平台下可扩展的分布式协调服务管理方法，其特征在于，包括以下步骤: (I)以中间节点交叉树林的组织方式对分布式集群的所有节点进行初始化； (2 )所有成员节点根据来自中心管理节点的全局网络拓扑结构查询出本节点的父子成员节点信息，所有父子成员节点之间以心跳机制进行信息同步和通信； (3)成员节点判断是否从其它成员节点接收到成员状态变更信息，如果接收到则进一步判断该成员状态变更信息指示成员减少还是增加，如果是减少则转入步骤(4)，如果是增加则转入步骤(7)，如果没有接收到则持续监听来自其它成员节点的成员状态变更信息； (4)成员节点判断是否接收到来自父节 点或子节点的心跳信息，如果接收到则根据心跳信息封装出一个成员状态变更信息，并将其发送到中心管理节点，然后转入步骤(5)，否则该成员节点继续监听来自父节点或子节点的心跳信息； (5)中心管理节点判断来自成员节点的成员状态变更信息是否正确，如果正确则更新全局网络拓扑结构，并将更新后的全局网络拓扑结构发送到所有的根成员节点，再由根成员节点分发给它的子孙成员节点，然后转入步骤(6)，否则等待接收来自其他成员节点的成员状态变更信息； (6)所有成员节点根据更新后的全局网络拓扑图更新其本地的网络拓扑结构； (7)成员节点根据成员状态变更信息判断是否有新的成员节点请求获取全局网络拓扑结构，若是则向中心管理节点发送报告信息，以请求中心管理节点为该新的成员节点分配颜色信息，然后转入步骤(8)，否则成员节点继续监听是否有成员状态变更信息。 (8)中心管理节点根据报告信息为该新成员节点分配颜色信息，并更新其自身的全局网络拓扑结构，并将新后的全局网络拓扑结构发送到新的成员节点，转入步骤(9)，同时也将更新后的全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它所有的子孙成员节点，转入步骤(6)； (9)新的成员节点根据来自中心管理节点的更新后的全局网络拓扑结构更新其本地的网络拓扑结构，并根据更新后的网络拓扑结构查询其父子成员节点信息，并与其父子成员节点建立心跳联系。
2.根据权利要求1所述的分布式协调服务管理方法，其特征在于，步骤(1)具体包括以下子步骤: (1-1)分布式集群中的中心管理节点接收管理员对分布式集群所有节点的命名nodel，node2,…，noden，其中η为分布式集群中节点的总数，并将该命名信息同步到所有节点； (1-2)中心管理节点对分布式集群的颜色集、最大树数和最大子节点数进行配置，并将配置结果作为限制参数转发给所有成员节点，用于对整个分布式集群的拓扑结构进行限定; (1-3)中心管理节点在分布式集群启动后将颜色集分配给所有节点，然后根据每个节点的颜色、IP地址以及步骤(1-2)中配置的最大树数和最大子节点数构建由多棵树组成的全局网络拓扑图，如图1所示； (1-4)中心管理节点为全局网络拓扑结构设定版本格式、初始版本号以及递增方式,并将该全局网络拓扑结构分发给所有树的根成员节点，再有根成员节点分发给它的子孙成员节点。
3.根据权利要求1所述的分布式协调服务管理方法，其特征在于，编号为nodel的节点即为中心管理节点，其它节点为成员节点。
4.根据权利要求1所述的分布式协调服务管理方法，其特征在于，步骤(1-3)中全局网络拓扑的构建过程遵循以下原则: (1-3-1)相同颜色的节点集中在一棵树的根节点或中间节点，且分散在其它树的叶子节点中； (1-3-2 ) —个节点可以同时出现在多棵树中，但每个节点只能在一棵树中充当根节点或者中间节点； (1-3-3)新节点应该插入到与之同颜色的树中最靠近根节点的节点中，且该节点中子节点的数目未超过最大子节点数； (1-3-4) —个节点的子节点数目达到最大子节点数时，新插入的节点应该插入到该节点的子树中，并且被插入的子树是所有子树中高度最矮或者子孙节点数目最少的； (1-3-5)当全局网络拓扑结构中树的总数达到最大树数时，如果再有新节点加入分布式集群，则不为该新节点创 建新的树结构，而是将该新节点插入已有的树结构中。
5.根据权利要求1所述的分布式协调服务管理方法，其特征在于，步骤(3)中，成员节点与其他某个成员节点的心跳机制突然中断时，表明该成员节点收到了成员减少的成员状态变更信息，成员节点收到了它所维护的全局网络拓扑结构中不存在的新的成员节点的心跳信息时，表明该成员节点收到了成员增加的成员状态变更信息。
6.根据权利要求1所述的分布式协调服务管理方法，其特征在于，步骤(5)中，如果中心管理节点同时接收到来自一个以上成员节点的成员状态变更信息，则表示成员状态变更信息是正确的，如果仅接收到来自一个成员节点的成员状态变更信息，则表示成员状态变更息是错误的。
【文档编号】H04L12/753GK103780497SQ201310749438
【公开日】2014年5月7日 申请日期:2013年12月30日 优先权日:2013年12月30日
【发明者】石宣化, 金海 , 吴松, 王秋月, 林浩泓, 陆路 申请人:华中科技大学