CN118093725A - 一种超大规模分布式集群架构及数据处理方法 - Google Patents

Abstract

本发明公开了一种超大规模分布式集群架构及数据处理方法，超大规模分布式集群架构中，集群被划分为多个数据中心，所述每个数据中心内设置内元数据管理节点和数据节点；在所有数据中心之上部署有拓扑管理节点；其中：所述内元数据管理节点，用于管理整个数据中心内部的元数据信息；所述数据节点用于数据的写入和查询；所述拓扑管理节点用于存储命名空间和数据中心的路由规则，对跨区域的操作进行统一协调，可以缩小元数据变更的影响范围，减轻集群区域管理节点的负载压力，拓扑管理节点也可以拓展为多层，便于超大集群管理，增强了集群的容错性。

Description

一种超大规模分布式集群架构及数据处理方法

技术领域

本发明涉及分布式数据库架构技术领域，尤其涉及一种超大规模分布式集群架构及数据处理方法。

背景技术

随着集群规模的增长，元数据可能变更频繁，单个或少数几个中心化的元数据服务就可能无法高效处理所有的元数据请求，成为系统的瓶颈。

Hbase、Elastisearch二者都属于混合的分布式架构，融合了主从架构、分布式协调服务架构等多种分布式架构模式的设计理念。HBase使用HMaster的组件来管理集群的元数据，在超大规模集群中，单个HMaster节点的资源限制成为了瓶颈，HBase依赖ZooKeeper管理节点元数据，ZooKeeper设计用于管理协调数据而非大量数据，因此在处理大规模的元数据时，ZooKeeper的性能可能成为瓶颈。

像Elastisearch这类，单个master对成百上千的节点的元数据变更都要进行同步，增加了master的负载，会导致集群有大量需要master协调处理的任务堆积，影响集群整体的稳定性和性能。目前对这种现象没有太好的处理办法，只能拆分集群为多个小集群，但这样又给运维工作带来大量额外负担。

发明内容

本发明的主要目的在于提供一种超大规模分布式集群架构及数据处理方法，对集群元数据采用多级管理的方式将集群的元数据变更进行解耦，缩小元数据变更的影响范围，减轻集群节点的负载压力，增强集群的容错性。

为实现上述目的，本申请第一方面提供一种超大规模分布式集群架构，集群被划分为多个数据中心，所述每个数据中心内设置内元数据管理节点和数据节点；在所有数据中心之上部署有拓扑管理节点；其中：

所述内元数据管理节点，用于管理整个数据中心内部的元数据信息；

所述数据节点用于数据的写入和查询；

所述拓扑管理节点用于存储命名空间和数据中心的路由规则，对跨区域的操作进行统一协调。

可选的，所述每个数据中心还包含协调节点，用于：接收用户请求并进行转发，缓存所述命名空间的路由信息。

可选的，所述集群的元数据同步采用 Raft分布式协议，一个节点中存在至多两个Raft组：

第一Raft组，用于管理所述命名空间到所述数据中心的路由规则；

第二Raft组，用于管理所述数据中心内的元数据。

另一方面，本申请还提出一种数据处理方法，应用于如第一方面所述的任意一种超大规模分布式集群架构；跨区域经多级路由修改元数据时，所述方法包括：

客户端向第一数据中心请求创建一个collection，该collection属于命名空间B；

所述第一数据中心接收创建所述命名空间B的collection请求，检测到所述命名空间B不匹配本地的路由规则，上溯至对应的拓扑管理节点A；

所述拓扑管理节点A检测路由规则同样不匹配，继续上溯到高一级的拓扑管理节点M；

所述拓扑管理节点M检测到所述命名空间B匹配拓扑管理节点B的路由规则，转发到所述拓扑管理节点B；

所述拓扑管理节点B检测到匹配第二数据中心的路由规则，转发至所述第二数据中心；

所述第二数据中心执行创建collection的请求，将请求结果返回；

所述请求结果经所述拓扑管理节点B、所述拓扑管理节点M、所述拓扑管理节点A最终原路返回至所述第一数据中心；

所述第一数据中心将创建结果返回给所述客户端。

可选的，所述方法包括：

负载均衡器向数据中心的协调节点发起请求；

若所述协调节点缓存的元数据足以处理所述请求则进行协调处理；否则，向所述数据中心的内元数据管理节点索要对应元数据，然后再进行协调处理。

可选的，在当前请求的数据中心内创建collection时，具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

所述第一数据中心的协调节点确认当前数据中心存在namespaceA，然后经当前数据中心的内元数据管理节点创建collectionA；

所述第一数据中心的内元数据管理节点执行创建collectionA，并指定shard创建的节点；

返回创建结果到所述第一数据中心的协调节点。

可选的，跨区域创建collection时，具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

第一数据中心的协调节点发现当前数据中心没有namespaceA，通过当前数据中心的内元数据管理节点向所述拓扑管理节点转发该请求；

所述拓扑管理节点查询到namespaceA在第二数据中心，将创建请求转发到所述第二数据中心的内元数据管理节点；

所述第二数据中心的内元数据管理节点查看当前数据中心没有collectionA，执行创建；

返回创建结果到所述第一数据中心的协调节点。

可选的，所述方法还包括写入文档数据流程，具体包括：

分片通过内元数据管理节点内collection的元数据计算出Schema diff；

如果Schema diff为空，直接写入新增文档数据；

否则，向所述内元数据管理节点发送Schema diff以更新Schema；

所述内元数据管理节点接收请求，应用Schema diff，将新的Schema同步给所述数据中心内所有节点；

所述分片得到更新后的Schema，用所述更新后的Schema写入文档数据。

可选的，所述方法还包括查询数据流程，具体包括：

协调节点根据查询请求指定的命名空间获取对应的collection的shard路由，并发送查询请求到各个shard，执行查询；

所述各个shard返回查询结果到所述协调节点，并合成最终查询结果。

可选的，所述方法还包括扩展数据中心的流程，新数据中心内部包括一个用于同步所述拓扑管理节点的路由规则的服务；该方法具体包括：

通过所述服务配置所述拓扑管理节点的地址，启动后自动向所述拓扑管理节点发送加入请求；

所述拓扑管理节点通过Raft的同步机制将新节点加入到集群中。

本申请提供一种超大规模分布式集群架构及数据处理方法，超大规模分布式集群架构中，集群被划分为多个数据中心，所述每个数据中心内设置内元数据管理节点和数据节点；在所有数据中心之上部署有拓扑管理节点；其中：所述内元数据管理节点，用于管理整个数据中心内部的元数据信息；所述数据节点用于数据的写入和查询；所述拓扑管理节点用于存储命名空间和数据中心的路由规则，对跨区域的操作进行统一协调；将大规模集群进行区域划分，每个数据中心有自己的内元数据管理节点和数据节点，只管理各自的元数据，缩小元数据变更的影响范围，减轻各数据中心内部节点的负载压力；在所有数据中心之上还有一个拓扑管理节点对跨区域的操作进行统一协调，在其不可用的情况下，各数据中心也能承载不跨区的一部分请求，拓扑管理节点也可以拓展为多层，便于超大集群管理，增强了集群的容错性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

其中：

图1为本申请实施例所提供的一种超大规模分布式集群架构示意图；

图2为本申请实施例所提供的一种采用Raft同步的架构示意图；

图3为本申请实施例所提供的另一种采用Raft同步的架构示意图；

图4为本申请实施例所提供的一种高可用区部署示意图；

图5为本申请实施例所提供的一种拓扑管理节点的路由规则存储示意图；

图6为本申请实施例所提供的另一种高可用区部署示意图；

图7为本申请实施例所提供的另一种拓扑管理节点的路由规则存储示意图；

图8为本申请实施例所提供的一种跨区域经多级路由修改元数据的流程示意图；

图9为本申请实施例所提供的一种在当前请求的Region内创建collection的流程示意图；

图10为本申请实施例所提供的一种跨Region创建collection的流程示意图；

图11为本申请实施例所提供的一种写入文档数据流程示意图；

图12为本申请实施例所提供的一种查询数据流程示意图；

图13为本申请实施例所提供的一种扩展区域流程示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请实施例中涉及到的元数据，其相关基本概念介绍如下：

文档(Document): 搜索引擎处理的对象；每个文档具有一个唯一的编号，称为文档编号(Document ID)；

文档集合(Document collection): 一组文档；

分区(Partition): 对collection内文档的逻辑划分，即给定一个Document ID能通过特定算法得到它所属的partition；默认一个collection被分为256个partition；

分片(Shard): 对collection内文档的物理划分，一个Shard包含若干个partition，文档读写的请求会通过partition被路由到对应的shard上；默认全部256个partition都被分配给一个Shard；

命名空间（Namespace）: 本设计支持多租户架构，允许在一个集群里面按不同场景对多个collection进行划分，相同场景下的一组collection属于同一命名空间；

Schema：每个collection有一个Schema，Schema指示文档的字段属性，每当有文档新增时，Schema也要随之演进更新，以保证Schema能描述collection内全部文档的属性。

本申请实施例中集群被划分为多个数据中心（Region），上述每个数据中心内设置内元数据管理节点（Catalog Manager）和数据节点（Data Node）；在所有数据中心之上部署有拓扑管理节点（Topology Manager）；其中：

上述内元数据管理节点，用于管理整个数据中心内部的元数据信息；

上述数据节点用于数据的写入和查询；

上述拓扑管理节点用于存储命名空间和数据中心的路由规则，对跨区域的操作进行统一协调。

本申请实施例中，主要对集群元数据采用多级管理的方式将集群的元数据变更进行解耦，集群中具有处理请求能力的最小单位称为一个数据中心（Region）。每个数据中心有自己的主节点，本申请中称为内元数据管理节点，即Catalog Manager，只管理本Region内部的元数据。这样缩小了元数据变更的影响范围，以减轻Region内部的主节点的压力。在至少两个Region之上设置拓扑管理节点，即Topology Manager，对跨区域（Region）的操作进行统一协调的服务。

可以理解为，如果评估单个Region规模增长过快，可以动态增加一个Region，把新增的节点都放在这个新Region下。这两个Region组成一个更大的集群，可称为一个区域（Zone）。每个Zone需要配置一个对跨Region的操作进行统一协调的服务，叫作TopologyManager。这个服务不会参与各Region内部的元数据，因此压力很小，并且在TopologyManager不可用的情况下，各个Region也能处理不跨区的请求，增强了集群的容错性。

可选的，Topology Manager可以由多个节点组成以实现高可用，TopologyManager 也可以随规模而扩展为多层，从而组成超大规模的集群。

下面结合本申请实施例中的附图对本申请实施例进行描述。

请参阅图1，为本申请实施例提供的一种超大规模分布式集群架构示意图。如图1所示，表示的是由一层Topology Manager管理的有多个Region组成的集群的分布式架构，其中示出了三个Region：Region A、Region B、Region C，每个Region可以简单看成是一个子集群，具备完整的处理请求的能力，Region内都有自身的主节点即Catalog Manager，以及数据节点（Data Node）；元数据和数据的管理通过Region来进行拆分，可以让集群达到上万节点的规模，让超大规模的数据管理成为可能。

在一种可选的实施方式中，上述每个数据中心还包含协调节点，用于：接收用户请求并进行转发，缓存上述命名空间的路由信息。

上述协调节点类似于网关功能，也称为Gateway Node。

具体的，如图1所示的集群的角色可以划分为以下几种：

拓扑管理节点（Topology Manager）：

存储namespace和Region的路由规则，用于跨Region通信时用，路由规则将在后续进行详细介绍。

具备管理Region的接口，可以通过此接口把Region注册到当前TopologyManager，或者删除Region。

不参与Region内的元数据同步。

Topology manager在离线/不可用的情况下，也不影响各个 Region 处理非跨区请求的能力。

Topology manager通过Raft将namespace路由规则同步到辖区内的Region。

Region内元数据管理节点（Catalog Manager）：

Catalog Manager管理整个Region内部的元数据信息，包括collection对应的Schema和Shard路由信息等。

当Region内部需要访问一个不存在的namespace时，Catalog Manager会自动上溯到Topology Manager，通过namespace路由规则判断该namespace是否存在，若存在，是在哪个Region内。

Catalog Manager通过Raft将元数据同步到Region内所有节点。

数据节点（Data Node）：用来承载数据的写入和查询。

协调节点（Gateway Node）：

接收用户请求并进行转发，缓存namespace的路由信息，缓存可以使用LRU 机制，只保留最近访问的N条路由，缓存仅在读取namespace路由信息时生效，涉及namespace路由变动时，必须经由Topology Manager协调。

在一种可选的实施方式中，上述集群的元数据同步采用Raft分布式协议，一个节点中存在至多两个Raft组：

第一Raft组，用于管理上述命名空间到上述数据中心的路由规则；

第二Raft组，用于管理上述数据中心内的元数据。

具体的，本申请实施例中元数据的同步可依赖Raft协议。集群的元数据同步采用Raft分布式协议来同步，一个节点中可能存在至多两个Raft组：

Zone的Raft组，称为Topology Manager，管理namespace到Region路由规则；

Region的Raft组，称为Catalog Manager，管理Region内的元数据。

在一个Raft组中，每个节点被赋予下述的某个角色：

Leader: 负责元数据的写入；

Candidate: 当Leader下线时，参与选举，成为新的Leader；

Follower: 从Leader节点订阅元数据更新日志。

一个Raft组内通常配置2个 Candidate以保证该Raft组内元数据的高可用性。

例如，图2为本申请实施例提供的一种采用Raft同步的架构示意图。如图2所示，表示Zone的Raft组，Topology Manager管理namespace到Region路由规则，通过Raft协议将路由规则同步到所管辖Region内的Follower节点，以同步Region间的路由信息。

图3为本申请实施例提供的另一种采用Raft同步的架构示意图。如图3所示，表示Region的Raft组，如前文所属，一个Region中需要配置Topology Manager 的Follower节点，以同步namespace路由规则；Catalog Manager负责将collection元数据同步到Region内的所有节点。

基于上述集群架构的描述，在此基础上，本申请实施例还提供一种超大规模分布式集群架构的数据处理方法，以实现跨区域多级路由对元数据进行请求，该方法可以应用于图1所示实施例中的超大规模分布式集群架构或其类似结构。

首先，在跨区域经多级路由修改元数据时，上述方法包括：

客户端向第一数据中心请求创建一个collection，该collection属于命名空间B；

上述第一数据中心接收创建上述命名空间B的collection请求，检测到上述命名空间B不匹配本地的路由规则，上溯至对应的拓扑管理节点A；

上述拓扑管理节点A检测路由规则同样不匹配，继续上溯到高一级的拓扑管理节点M；

上述拓扑管理节点M检测到上述命名空间B匹配拓扑管理节点B的路由规则，转发到上述拓扑管理节点B；

上述拓扑管理节点B检测到匹配第二数据中心的路由规则，转发至上述第二数据中心；

上述第二数据中心执行创建collection的请求，将请求结果返回；

上述请求结果经上述拓扑管理节点B、上述拓扑管理节点M、上述拓扑管理节点A最终原路返回至上述第一数据中心；

上述第一数据中心将创建结果返回给上述客户端。

为了更好地说明可扩展的跨区域多级路由机制，下面结合附图举例说明本架构弹性扩展多级路由的能力。

可以参考图4，图4为本申请实施例提供的一种高可用区部署示意图。如图4所示，在北京区部署了3个数据中心（Region），分别位于廊坊、顺义和大兴，每个数据中心（以下用地名代称，例如廊坊表示廊坊数据中心）代表一个可用区，3个可用区组成了北京高可用区(Available Zone，AZ），简称北京区。

各个数据中心把自己的路由规则上报给北京区的Topology Manager，由TopologyManager统一协调。

图5为本申请提供的一种拓扑管理节点的路由规则存储示意图。具体的，如图4所示的北京区的Topology Manager存储的路由规则说明如下：

图5中“廊坊”、“顺义” 、“大兴”方框表示该Region的namespace匹配规则，匹配规则的表现形式有多种，可以是特定的namespace前缀，例如 langfang_namesapce1表示以langfang开头的namespace应该被路由到廊坊数据中心；

可选的，可以使用namespace集合，例如{ namespace_1, namespace_2,namespace_3 }表示该集合内的namespace应该被路由到廊坊数据中心。

图6为本申请提供的另一种高可用部署示意图。具体的，在图4的基础上增加了上海高可用区，类似的，在上海区部署了3个数据中心（Region），分别位于浦东、静安和虹口，每个数据中心代表一个可用区，3个可用区组成了上海高可用区，简称上海区。在上海区和北京区之上组成中国区。

本申请实施例中的Topology Manager支持纵向多级扩展，因此上述北京高可用区和上海高可用区可以组成一个更大的区域，中国区。

图7为本申请提供的另一种拓扑管理节点的路由规则存储示意图。具体的，如图6所示的中国区Topology Manager存储的路由规则与前述示意图类似，图6中“北京区”、“上海区”方框表示该Region的namespace匹配规则，此处不再赘述。

图8为本申请实施例提供的一种跨区域经多级路由修改元数据的流程示意图。如图8所示，具体流程包括：

客户端向廊坊请求创建一个collection，这个collection属于命名空间B（namespace B）；

廊坊接收创建namespace B的collection请求，发现namespace B不匹配本地的路由规则，上溯至北京区；

北京区Topology Manager检测路由规则同样不匹配，继续上溯；

中国区Topology Manager发现namespace B匹配上海区的路由规则，转发至上海区；

上海区Topology Manager发现匹配浦东数据中心的路由规则，转发至该数据中心；

浦东数据中心执行创建collection 的请求，将请求结果返回；

请求结果经上海区、中国区、北京区最终原路返回至廊坊数据中心；

廊坊将创建结果返回给客户端。

以上仅为一种架构和数据处理示意，在实际应用中可以根据需要调整架构和进行相应的数据请求、转发和处理流程，本申请实施例对此不做限制。

在容错性设计方面，具体的，关于分片亲和性以及数据局部性：

本架构采用了最小影响范围的设计，当创建collection时，可以限制shard 的分配节点范围，使得collection固定在某些节点上，防止影响Region内其他collection的稳定性，增强了集群整体的稳定性和可预测性。

Topology manager 节点不可用时，不会影响下面各Catalog Manager管理的集群的正常读写操作，跨Region的操作除外，可以快速失败。

Catalog manager 节点不可用时，不影响Region内部的collection 正常执行写入数据，前提是schema没有变更；不影响Region内部查询操作。

按照上述设计，可实现将跨越全球的不同区域的集群组成一个既能相互请求又不会对彼此的运行增加负载的超大规模集群联盟。每个数据中心的内元数据管理节点只负责管理自己集群的元数据，不会受其他区域集群写入的干扰，也就保证了每个区域管理的元数据是有限的，不会无限制增长。并且拓扑管理节点也可以拓展为多层，可以在统一一个地方增加或移除某个区域的集群，既达到了统一管理的目的，又最大程度的避免了运维的复杂度。可选的，可以根据需要将上述集群架构应用到其他场景，并适应性调整其具体结构，本申请实施例对此不做限制。

下面对不同请求的网络拓扑进行说明。

在一种实施方式中，在当前请求的数据中心内创建collection时，该方法具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

上述第一数据中心的协调节点确认当前数据中心存在namespaceA，然后经当前数据中心的内元数据管理节点创建collectionA；

上述第一数据中心的内元数据管理节点执行创建collectionA，并指定shard创建的节点；

返回创建结果到上述第一数据中心的协调节点。

以创建namespaceA:collectionA为例，在当前请求的Region内创建collection时：

请参见图9，图9为本申请实施例提供的一种在当前请求的Region内创建collection的流程示意图，该方法包括：

1、Load Blancer向RegionA的Gateway发起创建namespaceA:collectionA的请求；

2、Gateway确认当前Region存在namespaceA，然后经Catalog Manager创建collectionA；

3、Catalog Manager执行创建collection A，并指定Shard创建的节点；

4、返回创建成功给Gateway。

在一种可选的实施方式中，跨区域创建collection时，该方法具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

第一数据中心的协调节点发现当前数据中心没有namespaceA，通过当前数据中心的内元数据管理节点向上述拓扑管理节点转发该请求；

上述拓扑管理节点查询到namespaceA在第二数据中心，将创建请求转发到上述第二数据中心的内元数据管理节点；

上述第二数据中心的内元数据管理节点查看当前数据中心没有collectionA，执行创建；

返回创建结果到上述第一数据中心的协调节点。

以创建namespaceA:collectionA为例，在跨Region创建collection时：

请参见图10，图10为本申请实施例提供的一种跨Region创建collection的流程示意图，该方法包括：

1、Load Blancer向Region A的Gateway发起创建namespaceA:collectionA的请求，namesapceA实际位于RegionB；

2、Gateway发现当前Region没有namespaceA，通过当前Region的Catalog Manager向Topology Manager转发请求；

3、Topology Manager查询到namespaceA在RegionB上，将创建请求转发到RegionB的Catalog Manager；

4、RegionB的Catalog Manager查看当前没有collectionA，执行创建；

5、创建成功后，原路返回给RegionA的Geteway。

请参见图11，图11为本申请实施例提供的一种写入文档数据流程示意图。写入数据涉及到schema变更请求时，只在Region内部流转，不影响其他Region。

如前文所属，新增文档时，需要更新collection的Schema，可以通过特定算法得到新旧Schema的差异，称为diff，对旧Schema应用该diff可以得到新 Schema。该方法具体可包括：

Shard通过Catalog Manager内Collection的元数据计算出Schema diff；

如果diff为空，直接写入新增文档数据；

否则，向Catalog Manager发送diff以更新Schema；

Catalog Manager接收请求，应用diff，将新的Schema同步给Region内所有节点；

Shard得到更新后的Schema，随后用新的Schema写入文档数据。

请参见图12，图12为本申请实施例提供的一种查询数据流程示意图。如图12所示，Gateway根据查询请求指定的namespace获取对应的collection的Shard路由，并发送查询请求到各个Shard，执行查询；

各个Shard返回查询结果给Gateway，并合并（merge）成最终查询结果。

请参见图13，图13为本申请实施例提供的一种扩展区域流程示意图。如图13所示，新Region内部有一个用于同步Topology Manager路由规则的服务，会配置TopologyManager的地址，启动后自动向Topology Manager发送join请求。

Topology Manager通过Raft的同步机制来把新节点加入到集群中。

在本申请的一个实施例中，还提出了一种电子设备。该电子设备可包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，将执行如本申请实施例中所示方法实施例中的任意步骤。该电子设备还可以包括输入/输出设备等。在具体的实施方式中，该电子设备可以为终端设备等。

在一个实施例中，还提出了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行上述方法实施例中的任意步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink) DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种超大规模分布式集群架构，其特征在于，集群被划分为多个数据中心，所述每个数据中心内设置内元数据管理节点和数据节点；在所有数据中心之上部署有拓扑管理节点；其中：

所述内元数据管理节点，用于管理整个数据中心内部的元数据信息；

所述数据节点用于数据的写入和查询；

所述拓扑管理节点用于存储命名空间和数据中心的路由规则，对跨区域的操作进行统一协调。

2.根据权利要求1所述超大规模分布式集群架构，其特征在于，所述每个数据中心还包含协调节点，用于：接收用户请求并进行转发，缓存所述命名空间的路由信息。

3.根据权利要求1所述超大规模分布式集群架构，其特征在于，所述集群的元数据同步采用 Raft分布式协议，一个节点中存在至多两个Raft组：

第一Raft组，用于管理所述命名空间到所述数据中心的路由规则；

第二Raft组，用于管理所述数据中心内的元数据。

4.一种超大规模分布式集群架构的数据处理方法，其特征在于，应用于权利要求1-3任一项所述的超大规模分布式集群架构；在跨区域经多级路由修改元数据时，所述方法包括：

客户端向第一数据中心请求创建一个collection，该collection属于命名空间B；

所述第一数据中心接收创建所述命名空间B的collection请求，检测到所述命名空间B不匹配本地的路由规则，上溯至对应的拓扑管理节点A；

所述拓扑管理节点A检测路由规则同样不匹配，继续上溯到高一级的拓扑管理节点M；

所述拓扑管理节点M检测到所述命名空间B匹配拓扑管理节点B的路由规则，转发到所述拓扑管理节点B；

所述拓扑管理节点B检测到匹配第二数据中心的路由规则，转发至所述第二数据中心；

所述第二数据中心执行创建collection的请求，将请求结果返回；

所述请求结果经所述拓扑管理节点B、所述拓扑管理节点M、所述拓扑管理节点A最终原路返回至所述第一数据中心；

所述第一数据中心将创建结果返回给所述客户端。

5.根据权利要求4所述数据处理方法，其特征在于，所述方法包括：

负载均衡器向数据中心的协调节点发起请求；

若所述协调节点缓存的元数据足以处理所述请求则进行协调处理；否则，向所述数据中心的内元数据管理节点索要对应元数据，然后再进行协调处理。

6.根据权利要求5所述数据处理方法，其特征在于，在当前请求的数据中心内创建collection时，具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

所述第一数据中心的协调节点确认当前数据中心存在namespaceA，然后经当前数据中心的内元数据管理节点创建collectionA；

所述第一数据中心的内元数据管理节点执行创建collectionA，并指定shard创建的节点；

返回创建结果到所述第一数据中心的协调节点。

7.根据权利要求5所述数据处理方法，其特征在于，跨区域创建collection时，具体包括：

负载均衡器向第一数据中心的协调节点发起创建namespaceA:collectionA的请求；

第一数据中心的协调节点发现当前数据中心没有namespaceA，通过当前数据中心的内元数据管理节点向所述拓扑管理节点转发该请求；

所述拓扑管理节点查询到namespaceA在第二数据中心，将创建请求转发到所述第二数据中心的内元数据管理节点；

所述第二数据中心的内元数据管理节点查看当前数据中心没有collectionA，执行创建；

返回创建结果到所述第一数据中心的协调节点。

8.根据权利要求5所述数据处理方法，其特征在于，所述方法还包括写入文档数据流程，具体包括：

分片通过内元数据管理节点内collection的元数据计算出Schema diff；

如果Schema diff为空，直接写入新增文档数据；

否则，向所述内元数据管理节点发送Schema diff以更新Schema；

所述内元数据管理节点接收请求，应用Schema diff，将新的Schema同步给所述数据中心内所有节点；

所述分片得到更新后的Schema，用所述更新后的Schema写入文档数据。

9.根据权利要求5所述数据处理方法，其特征在于，所述方法还包括查询数据流程，具体包括：

协调节点根据查询请求指定的命名空间获取对应的collection的shard路由，并发送查询请求到各个shard，执行查询；

所述各个shard返回查询结果到所述协调节点，并合成最终查询结果。

10.根据权利要求5所述数据处理方法，其特征在于，所述方法还包括扩展数据中心的流程，新数据中心内部包括一个用于同步所述拓扑管理节点的路由规则的服务；该方法具体包括：

通过所述服务配置所述拓扑管理节点的地址，启动后自动向所述拓扑管理节点发送加入请求；

所述拓扑管理节点通过Raft的同步机制将新节点加入到集群中。