CN104035836B - 集群检索平台中的自动容灾恢复方法及系统 - Google Patents

Abstract

本申请公开了集群检索平台中的自动容灾恢复方法及系统，该方法包括：在中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；在第一动态信息数据结构中保存当前机器状态信息，在各个第二数据结构中保存各个副本的当前状态信息；根据当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；如果存在，则根据当前机器状态信息以及各个副本的当前状态信息，为需要进行恢复的副本选择目标检索节点；由所述目标检索节点根据所述索引文件提供检索服务。通过本申请，能够在自动容灾恢复过程中，更好地保证系统的稳定性。

Description

集群检索平台中的自动容灾恢复方法及系统

技术领域

本申请涉及容灾恢复技术领域，特别是涉及集群检索平台中的自动容灾恢复方法及系统。

背景技术

对于搜索引擎而言，在索引量和搜索量大到一定程度的时候，索引更新的效率会逐渐降低，并且服务器的压力也会逐渐升高，因此，基本上整个搜索引擎的利用率可以说是越来越低了，由此，分布式检索技术便应运而生了。

基于服务器集群的检索系统便是分布式检索技术中的一种，这种系统将检索业务部署到多个节点中。Solr是一个独立的企业级搜索应用解决方案，在Solr的方案中，每个搜索应用会对应一个SolrCore的抽象，可以根据各个检索业务的业务规模合理分配承载SolrCore的机器，并实现M*N的索引模型。在这种M*N的索引模型下，承载同一检索业务的各台机器在逻辑上可以组成一个M*N(M行N列)的矩阵。当在该集群中时创建一个检索业务时，可以根据业务规模等为其选择矩阵的规模(也即，确定出M与N的取值)，然后，将检索业务的索引文件按一定的规则切分成N个分片，将各个分片分别部署到矩阵中水平向的各个不同的机器中，同样在此切分规则之下，对数据的访问请求也将按此规则分发到不同的机器中；同时，矩阵中位于同一列上的各个机器可以形成一个副本集，也即同一列的各个机器中保存有相同的索引文件备份，这样可以将来自应用服务器的请求访问(request visit)得以均匀的分布在同一列的各台机器上，用以减缓单台服务器在请求负载上的压力。也就是说，对于一个检索业务而言，在M*N的索引模型下，将会存在N个分片，每个分片存在M个副本，通过这种业务的划分以及冗余机制，可以实现负载均衡，同时也可以实现容灾机制，也即，由于同一分片在不同的机器中存在多个副本，因此，如果其中一台机器宕掉，同一列中的其他机器还可以继续提供检索服务。

但是，当某个M*N存储的搜索业务中的某个节点出现异常故障，如果M＝2，则可能导致该业务的某列的存活副本节点为1，此时，如果再出现该列的节点宕机，将会出现整个服务不可用情况。另外，当搜索业务接入方对搜索业务稳定性的要求持续增高，基于之前固定机器节点的M*N索引模型来支持7*24小时无故障搜索服务会变的越来越不可靠。首先，机器宕机故障后，只能通过报警通知才知道节点故障，然后人工才会参与去看什么原因导致宕机；其次，如果只是应用层的故障还好，一旦是物理层的机器坏掉，如硬盘、主板坏掉，遇到这种情况，整个服务的恢复时间完全不可控。

为了避免上述现象的发生，需要一个监控体系，当发现某个业务节点出现异常后，能及时准确的推选出一个或者多个空闲机器节点，以替换那些出现宕机的机器节点，同时快速对外提供正常的搜索服务。只有这样，整个搜索服务出现问题后能较快的重新恢复到稳定状态，而不需要等待原来宕机的机器修复后才能恢复到稳定状态。

目前，有些技术方案中是可以实现自动的容灾恢复，也即，可以自动恢复一个搜索节点替换之前出现问题的检索节点。在这种自动容灾恢复方案中，在发现一个机器宕掉之后，可以从其他的机器节点中随机地选择一台机器作为恢复节点，将该出现问题的节点上的检索工作转移到该恢复节点中，以此实现自动容灾恢复。但是，这种随机选择恢复节点的方式，会影响到系统的整体稳定性，甚至可能会对一个检索业务执行容灾恢复的过程中，对其他的检索业务造成影响。因此，需要一种更可靠的自动容灾恢复机制。

发明内容

本申请提供了集群检索平台中的自动容灾恢复方法及系统，能够在自动容灾恢复过程中，更好地保证系统的稳定性。

本申请提供了如下方案：

一种集群检索平台中的自动容灾恢复方法，所述集群检索平台包括中心节点以及用于提供检索服务的检索节点，所述方法包括：

在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

在所述第一动态信息数据结构中保存所述检索节点上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点上传的各个副本的当前状态信息；

根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

如果存在，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。

一种集群检索平台中的自动容灾恢复系统，所述集群检索平台包括中心节点以及用于提供检索服务的检索节点，所述系统包括：

数据结构创建单元，用于在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

信息保存单元，用于在所述第一动态信息数据结构中保存所述检索节点上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点上传的各个副本的当前状态信息；

判断单元，用于根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

节点选择单元，用于如果存在需要进行恢复的副本，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

恢复单元，用于将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请，可以抽象出一个中心节点CenterNode来掌控搜索平台中所有检索节点上的机器状态，以及各个检索节点上承载的所有业务的副本状态，这样，就可以根据这些状态信息来确定是否存在需要进行恢复的副本，如果存在，还可以根据机器状态信息以及副本的状态信息，来综合选择出最合适的目标检索节点，然后就可以在该节点上对副本进行恢复。可见，在本申请实施例中，在选择用于进行副本恢复的目标检索节点时，可以以各个检索节点的机器状态以及各个检索节点中各个业务副本的状态为依据，而不是进行随机选择，因此，可以在自动容灾恢复过程中，更好地保证系统的稳定性。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的搜索平台中业务发布过程的流程图；

图3是本申请实施例提供的状态信息获取方式的示意图；

图4是本申请实施例提供的系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了能够提供一个更可靠的自动容灾恢复机制，本申请实施例首先抽象出一个中心节点CenterNode来掌控搜索平台中所有业务的搜索引擎状态，并且通过状态信息分析来决定集群机器的下一步的动作是什么，比如，容灾恢复、组内扩容等。同时，集群中还存在检索节点CoreNode，该节点用于提供检索服务的节点，负责从CenterNode的任务池领取任务指令进行具体业务的引擎SolrCore(也即检索业务某分片的一个副本)的创建、变更、删除等动作，同时在引擎SolrCore对象正常创建后提供检索服务。

需要说明的是，在本申请实施例中，CoreNode中承载的副本也称为SolrCore副本，从功能上讲，其实是具体的检索业务的业务引擎，能够对外提供检索业务。

参见图1，本申请实施例提供的集群检索平台中的自动容灾恢复方法可以包括以下步骤：

S101：在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

S102：在所述第一动态信息数据结构中保存所述检索节点上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点上传的各个副本的当前状态信息；

在具体实现时，中心节点能够与检索节点之间进行通信，检索节点可实时上传状态信息到中心节点，中心节点进行保存，进而利用保存的状态信息执行后续的恢复需求判断以及目标检索节点的选择等操作。其中，中心节点为了对这些状态信息进行保存，可在中心节点中为各个检索节点创建对应的检索节点抽象：CorenodeDescrptor，在该CorenodeDescrptor中可以为各个检索节点创建用于保存机器状态信息的第一数据结构，以及分别用于保存检索节点中承载的各个SolrCore的状态信息的第二数据结构：动态DynCore。

其中，关于中心节点CenterNode与检索节点CoreNode之间具体如何进行信息的交互，下面进行详细地介绍。

在CoreNode启动后，将立即和CenterNode进行通信，同时自身将生成身份令牌并向CenterNode注册，该身份令牌可以包括一个随机数+IP地址+Port+当前系统时间等，CenterNode校验版本信息和令牌合法性后，查看该CoreNode是否是已经注册过的机器，有两种处理情况：

如果是未注册机器，CenterNode将找不到对应CoreNode的CoreNodeDescriptior(CoreNode节点抽象)，这个时候CenterNode初始化一个CoreNodeDescr iptior，并将它的存活状态置为0nline，然后将它加入到内存中存活机器列表池中(一个链表的数据结构)；

如果是已经注册过的机器，CenterNode将找到对应该CoreNode节点身份令牌的CoreNodeDescriptior，然后更新该节点抽象的基本信息，如IP、Port等信息。最后返回给CoreNode注册成功信息。

同时CoreNode如果是第一次注册，注册成功后将持久化身份令牌到本地，之后机器节点的重启导致的再次注册，都将用第一次持久化的身份令牌向CenterNode注册。

所有加入搜索集群中的CoreNode在承载SolrCore引擎的时候都是空闲节点，并不会提供任何的搜索服务出去(因为CoreNode中还没有保存索引文件等相关数据)。这个时候需要在后台进行具体业务的SolrCore引擎发布，才能让新的SolrCore引擎创建。整个执行流程为如图2所示。

S201：CoreNode选择：

CoreNode成功注册CenterNode后，CenterNode将会有一个对应该CoreNode的抽象，如果该CoreNode没有出现宕机，该抽象将会一直在CenterNode存在，在ManagerNode节点(该节点为整个引擎平台的后台管理节点，负责所有接入业务的发布和扩容、配置变更等指令触发，并提供整个引擎平台所有业务搜索引擎的状态信息可视化查询)通过页面选择好对应某个业务的CoreNode节点。选择规范必须满足M*N模型，即一个业务可以存在多个Shard分片、每个Shard分片存在多个副本。M*N的结构的索引存储结构可以有效解决负载均衡和宕机容灾问题。在ManagerNode节点需要做的是定义好数据模型的M、N的数目和每个矩阵对应的CoreNode机器IP。

S202：创建指令触发：

选择好所有的CoreNode机器后，点击创建指令，MangerNode将该任务指令通过进程RPC协议通知到CenterNode。CenterNode接到指令后将对该指令的业务名称进行校验，如果发现这个业务已经创建过，将返回错误给MangerNode。如果没有该业务对应的SolrCore引擎生成，则开始创建。

S203：NSEditLog记录操作：

创建操作的执行将会有一个预写事务日志(WAL)NSEditLog来保证节点崩溃时对SolrCore的创建操作的持久化。节点崩溃后重启将重做NSEditLo的记录，让节点内存中的数据结构恢复到崩溃前的状态。CenterNode重启过程中将会根据NSEditLog文件的记录按照顺序重做操作内容，从而让内存中数据结构恢复到宕机前某个时间点。

S204：NameSpaceFile生成：

NSEditLog记录生成后，对应的NameSpaceFile在内存的结构也就生成，从内存结构上看为：GenerationStamp创建时间戳记录、NameSpaceFile路径记录、NameSpaceFile路径修改、访问时间记录、NameSpaceFile文件内容记录，主要内容包括文件业务名、Shard数目、副本数目、修改时间、访问时间和该业务对应的SolrCore抽象Core的列表记录。NameSpaceFile是一个搜索业务在CenterNode中的一个管理抽象和业务抽象，而CenterNode对于每个业务的管理和操作都是基于NameSpaceFile进行，例如：扩容，容灾等。

S205：提交任务到任务池：

当一个业务归属的NameSpaceFile生成完毕后，接下来就需要将这个创建操作以任务的方式放入已经选择好CoreNode对应的CorenodeDescriptor抽象的任务池中。

S206：CoreNode领取任务：

当选择的CoreNode在一个心跳周期和CenterNode通过RPC通信后，将会到该CoreNode对应的CorenodeDescriptor任务池中领取到这个CoreNode需要执行的任务，同时将任务和需要创建的SolrCore对应的唯一身份CoreId连同任务类型一起封装成CoreNodeCommand返回给请求的CoreNode。

S207：SolrCore创建：

CoreNode节点心跳通信返回后，获取到指定的任务指令CoreNodeCommand，根据CoreNodeCommand任务类型选择相应任务执行。如果是SolrCore创建，CoreNode将会执行如下操作：

1)到ManagerNode去拉最新版本的SolrCore所需要的配置文件(schema.xml、solrConfig.xml等)；

2)CoreNode加载schema.xml和solrConfig.xml配置文件生成SolrCore对象；

3)将CoreNodeCommand中对应创建具体SolrCore唯一身份标示coreId和执行状态信息持久化到本地；

4)将创建SolrCore是否成功的标示通知到CenterNode。

成功创建完SolrCore之后，该引擎节点并没有任何索引数据，这个时候CenterNode接受到该应用所有M*N个SolrCore的成功创建通知后，将进行全量任务指令放入这些Solrcore对应的CorenodeDescriptor任务池中。接下来对应的CoreNode通过心跳通信领取全量任务进行全量。

每个SolrCore全量完毕后，将执行状态信息通知CenterNode，CenterNode收集到这个业务归属的所有SolrCore的全量执行成功通知后，将进行搜索服务发布的任务指令放入到这些SolrCore对应的CorenodeDescriptor任务池中。接下来，对应的CoreNode通过心跳通信领取搜索服务发布任务。

每个SolrCore的搜索服务发布后，将执行状态信息通知CenterNode，CenterNode收集到这个业务归属的所有SolrCore搜索服务发布成功通知后，将调用NSEditLog的0P_CLOSE操作，该操作将记录NameSpaceFile已经成功创建。

S208：动态信息变更：

参见图3，本申请实施例中的动态信息收集示意图，其中，DynCore是一个对具体CoreNode承载的SolrCore副本的抽象，一旦某个业务的一个分片下的副本在CoreNode成功创建后，则被中心节点的CorenodeDescriptor所创建并管理，也就是说哪个CoreNode承载了SolrCore的副本，那么就会在CorenodeDescriptor存在一个对应的DynCore。

同时，图2中可以看出，中心节点还可以存在NameSpaceFile，它是在创建一个搜索业务的时候就会在CenterNode生成的一个内存数据结构，主要内容包括该业务有几个分片、有几个副本、涉及配置文件名称等。比如，某个业务存在3个分片，那么就会在NameSpaceFile存在3个Core的抽象。这些信息基本是一旦发布后都不大会改变，除非出现扩容情况。

例如，图3说明一个分片为3，副本数为2的搜索业务分布在CoreNodeA、CoreNodeB、CoreNodeC中，每次CoreNode通过心跳通信，首先找到对应CoreNode的CorenodeDescriptor，并根据每个SolrCore副本对应的唯一身份coreId找到DynCore，然后更新这个DynCore的状态信息，这样每个机器中承载的各个SolrCore副本的状态信息都能在CenterNode有个内存映射。例如图2中搜索服务分片1和分片0的SolrCore副本抽象DynCore在CorenodeDescriptorA中，并同时对应着NameSpaceFile的Core-0对象，其他依次类推。同时，在中心节点的CorenodeDescriptor中还可存储有用于保存各个机器状态信息(包括可用磁盘空间大小、可用内存大小、当前负载的大小、CPU核心数量等)的数据结构(图中未示出)。

其中，DynCore主要管理SolrCore副本实时更新一些状态信息，包括：

SolrCore对应的Solr和Lucene引擎版本信息；

SolrCore对应业务名称；

SolrCore实例的系统路径；

SolrCore实例对应索引的存储路径；

SolrCore实例的索引大小；

SolrCore对应索引数据量大小；

SolrCore的执行状态信息(创建中、创建成功、全量中、全量成功、发布搜索服务等)；

SolrCore创建时间；

SolrCore搜索请求数；

SolrCore平均每秒响应多少次请求；

SolrCore每次请求平均响应时间；

SolrCore请求超时数；

SolrCore缓存状态信息(缓存大小、累计命中率、累计淘汰个数等)。

也就是说，CoreNode节点和CenterNode节点间的通信可以分为：

心跳通信(SendHeartbeat)；

健康状态汇报(CoreReport)。

其中，心跳通信主要是CoreNode将机器状态信息(包括CPU核心数量、可用内存大小、可以磁盘大小、搜索监控指标信息等)每隔一定时间(例如，三秒)汇报给CenterNode，CenterNode在前述第一数据结构中保存该机器状态信息。

而健康状态汇报是将该CoreNode上承载的所有SolrCore副本的健康状态信息上报给CenterNode，如SolrCore执行状态、是否正常工作等信息，以一定的间隔(例如3分钟)汇报给CenterNode节点，CenterNode在前述各个第二数据结构中保存各个SolrCore副本的状态信息。

S103：根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

由于中心节点CenterNode记录了各个CoreNode的机器状态信息，以及各个CoreNode中承载的各个SolrCore副本的状态信息，因此，可以根据这些信息可以及时发现需要进行恢复的副本。并且，由于中心节点记录的信息中不仅仅包括机器状态信息，还包括CoreNode中承载的各个SolrCore副本的状态信息，因此，中心节点不仅能发现机器宕机情况下需要恢复的副本，还可以发现在机器没有宕机但是副本运行不正常时需要恢复的副本。

也就是说，在确定需要恢复的副本时，本申请实施例中一方面可以判断是否有检索节点CoreNode发生了宕机，如果是，则可以将该CoreNode中承载的各个SolrCore副本都确定为需要进行恢复的SolrCore副本。

其中，具体在判断是否有CoreNode发生了宕机时，CenterNode可在后台有一个HeartbeatMonitor线程去判断CoreNode是否宕机，每个CoreNode通过心跳通信后都将更新CenterNode中对应的CorenodeDescriptor中的las tupdatTime为当前更新时间，在HeartbeatMonitor每隔一段时间进行轮询检查的时候，如果发现某个CorenodeDescriptor对应的lastupdateTime小于当前时间减去一个预置的安全时间间隔(lastupdateTime＜currentTime-heartbeatExpireInterval)，那么就会认为该Corenode已经宕机，一旦发现该情况，CenterNode将会认为这个CoreNode承载的所有SolrCore副本都为不正常状态，并将该CoreNode承载的所有SolrCore副本都加入到待恢复列表中(neededReplications)。

需要说明的是，在实际应用中，在通过上述方式来确定需要恢复的SolrCore副本时，加入到待恢复列表中的SolrCore副本可能会有误判情况。例如，如果某CoreNodeA当前因为网络、或者人工重启，导致在一个安全时间间隔没有和CenterNode进行心跳检查，这个时候CenterNode会误判该CoreNodeA已经宕机，并将其承载的SolrCore都加入到待恢复列表中。此时，如果直接对这些SolrCore副本都进行恢复，将会出现多余的副本，这将破坏原有的M*N模型，使得系统不够稳定。为了避免这种情况的发生，在本申请实施例中每次恢复操作之前，还可以检查待恢复的SolrCore副本当前在集群中总的副本存活数(因为一个SolrCore副本在矩阵的同一列中的M个机器中均存在SolrCore副本，因此，可以分别检查这M个机器中承载的这些SolrCore副本是否为存活状态，由此可以统计出存活副本的数目)，如果在此之前，该CoreNodeA又有汇报上来并且其中承载的SolrCore副本已经正常，则统计出的存活副本的数量可能是正常的(例如等于为对应的检索业务分配的副本数量)，因此，就可以直接将这些待恢复的SolrCore副本清除出列表，不再对其进行恢复。当然，如果是在执行了恢复任务之后，CoreNodeA才汇报上来并且其中承载的SolrCore副本已经正常，那么就会出现多余副本情况，这个时候CenterNode后台会仍然会监控这个副本存活数，如果存活副本数目大于实际为对应的检索业务分配的副本数，可触发一个删除多余副本数操作，将该业务下多余的副本进行删除。

另外，本申请实施例还可以根据CoreNode的健康状态上报的SolrCore副本的状态信息，来判断是否存在某个SolrCore副本已经不正常，如果存在，则CenterNode将该SolrCore副本加入到需要进行副本恢复的列表(neededReplications)中。

也就是说，对于一个CoreNode节点而言，可能并未发生宕机，但其中承载的SolrCore副本却可能已经不正常了，原因可能是索引文件被损坏等等。在本申请实施例中，由于中心节点能够监控到各个CoreNode承载的各个SolrCore副本的状态信息，因此，如果发生该现象，则中心节点能够及时发现，然后将该不正常的SolrCore副本作为需要恢复的SolrCore副本。

具体地，在判断是否存在不正常的SolrCore副本时，可以根据CoreNode节点上报的副本状态信息进行分析，如果其中某些信息项存在明显的错误，或者上报的副本状态信息中存在CoreNode节点添加的错误标识，则可以确定对应的SolrCore副本已经不正常。或者，还有些情况是，CoreNode节点应该为某SolrCore副本上报状态信息，但是，CenterNode在一定的时间间隔内却没有收到关于该SolrCore副本的状态信息，此时，CenterNode可以认为该SolrCore副本归属的检索业务应该是被删除了，因此，可以不必将其加入副本恢复列表中。

S104：如果存在，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

对于需要进行恢复的副本而言，如果要进行恢复，首先可确定在哪个CoreNode节点中进行恢复，在本申请实施例中，并不是随机地进行选择，这是因为，其他的CoreNode节点可能同时承载有其他检索业务的副本，并且可能已经是负载特别重的机器，如CPU的负载特别高、内存已经没有多少空闲、磁盘空间已经不够等；另外一种情况，有些CoreNode节点已经承载了核心业务的SolrCore搜索引擎，是不能容忍其他业务SolrCore引擎被承载。另外，如果某个CoreNode节点正在执行恢复操作，则如果向该CoreNode节点分配恢复任务，也可能会导致不稳定。总之，如果盲目地选择，可能会对其他检索业务产生影响，或者使得整个系统的负载不够均衡，影响系统效率，等等。

因此，在本申请实施例中，对机器的自动推选应该根据如下几种策略：

排除标示为不能承载其他业务的CoreNode；

排除磁盘空间不足的CoreNode；

排除已经被分配恢复任务并正在进行恢复的CoreNode。

对于剩余的CoreNode，根据CoreNode的多种维度(机器状态维度以及副本状态维度)加维度权重影响的打分排序，分数越高代表CoreNode越空闲。

在CenterNode中推选出最空闲机器其实就是推选出集群中所有CoreNode在CenterNode中对应的CorenodeDescriptor的过程。CorenodeDescriptor对象中会有一个Exclusive属性，如果为TRUE，则代表该CorenodeDescriptor只为一个业务的SolrCore独占。一旦设置为TRUE后，该节点就不会在自动推选最空闲机器结果集中出现，即使它的Load很低、内存、磁盘都很充裕。而Exclusive为FALSE的CorenodeDescriptor都可以根据打分机制被推选出来，作为进行容灾恢复的CoreNode节点。

一个业务引擎索引所需要的磁盘空间大概是当前索引的两倍左右，这是因为在全量任务结束后从HDFS中拷贝索引到本地，会出现新老索引并存情况，那么在全量切换时刻磁盘占用将会达到原来索引容量的两倍左右，所以在选择CoreNode的时候通常需要满足：当前磁盘空闲空间减去待恢复业务的索引磁盘容量的2倍(diskRemain-2*diskUsed＞0)大于0，如果不满足要求则将该CoreNode进行过滤，剩余满足磁盘空闲条件的CoreNode进入下一个过滤环节。

CoreNode在CenterNode中的抽象CorenodeDescriptor一旦被选中作为待恢复的节点后，在整个容灾恢复过程未完成前将不会再被选中为待恢复节点。从neededReplications待恢复列表中优先级最高的待恢复SolrCore选择合适的CorenodeDescriptor后，会将恢复任务放入pendingReplications(正在恢复列表)，凡是在正在恢复列表中的CorenodeDescriptor将不会再选中为待恢复机器。但是整个恢复过程会存在失败情况，所以，后台可以有线程去校验在一个安全预置时间内正在恢复的任务是否成功结束，如果没有，则认为该恢复任务失败，将该任务从pendingReplications清除，并将该任务重新放入neededReplications中，而此时CorenodeDescriptor又可以作为新的SolrCore待恢复的节点。

满足上述3个筛选条件后的机器节点将可基于如下2个大维度进行权重影响排序：

机器维度：

diskRemain：磁盘剩余空间

totalPhysicalMemorySize：内存大小

availableProcessors：CPU核数

systemLoadAverage：机器当前Load大小

业务SolrCore引擎维度：

coreNum：承载SolrCore的个数

avgTimePerRequest：每次请求的平均响应时间

上述两个维度可以按照权重影响的两种优先级进行筛选排序：

优先级1：

如果CoreNode没有承载任何SolrCore副本，即发现CorenodeDescriptor中并没有DynCore被分配，则将会认为是最空闲的机器，所以从排序计算来看coreNum为0的机器优先级为1(即将设置较大的权重值)，同时CoreNode的得分激励将会越高；如果多个CoreNode都没有承载SolrCore副本，则将磁盘空闲大的排序优先，磁盘一样的话则将可用内存较大的优先排序。所以优先级1下多个维度的权重值是：coreNum＝0＞磁盘空间＞内存。

优先级2：

如果CoreNode有承载SolrCore副本，则机器负载load为最大权重考虑，load越小分数越高，Load一致情况下，再以coreNum维度打分，coreNum越小则分数越高(coreNum越小代表部署的业务引擎副本越小，意味着影响面越小)。如果coreNum相同将会根据SolrCore平均每次请求响应时间(avgTimePerRequest，请求响应越小代表该节点的查询性能越好)来比较，avgTimePerRequest越低打分越高。所以优先级2下多维度的权重值为load＞coreNum＞avgTimPerRequests。

最终，在自动容灾过程中被推选出来的用于进行恢复的CoreNode节点，满足以下条件：

不被某一业务独占的；

能承载2倍待恢复业务索引磁盘空间的数据；

优先推选出集群中未部署业务引擎的并且是磁盘和内存较充裕的机器；

如果发现没有未部署业务引擎的机器节点，则选择出Load、承载引擎、平均响应时间较低的机器。

S105：将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。

副本恢复过程具体为，将待恢复列表中的SolrCore抽象重新创建，CenterNode后台会有ReplicationMonitor每隔一个时间间隔将待恢复列表中需要进行恢复的solrCore副本进行重新构建操作。

被选择的用于进行副本恢复的目标CoreNode节点从CenterNode获取任务后，开始进行SolrCore副本构建，大体流程和前文所述的SolrCore创建的流程一致，唯一不一样的是构建成功后将不会重新全量，也不是从其他正在运行的节点中去拷贝索引文件，而是从分布式平台(如Hadoop等，负责整个引擎平台所有业务引擎所需要的源数据和索引数据的存储)的HDFS文件系统上拉取最新的全量索引到本地，同时增补已经在HDFS上并且是全量时间点Timepoint后到目前为止的增量数据为索引，最后发布搜索服务，这样业务方的搜索请求就能进入到最新构建的CoreNode中来，整个过程对于业务方完全透明。

总之，在本申请实施例中，可以抽象出一个中心节点CenterNode来实时掌控搜索平台中所有检索节点上的机器状态，以及各个检索节点上承载的所有业务的副本状态，这样，就可以根据这些状态信息来确定是否存在需要进行恢复的副本，如果存在，还可以根据机器状态信息以及副本的状态信息，来综合选择出最合适的目标检索节点，然后就可以在该节点上对副本进行恢复。可见，在本申请实施例中，在选择用于进行副本恢复的目标检索节点时，可以以各个检索节点的机器状态以及各个检索节点中各个业务副本的状态为依据，而不是进行随机选择，因此，可以在自动容灾恢复过程中，更好地保证系统的稳定性。

与本申请实施例提供的集群检索平台中的自动容灾恢复方法相对应，本申请实施例还提供了一种集群检索平台中的自动容灾恢复系统，参见图4，所述集群检索平台包括中心节点以及用于提供检索服务的检索节点，所述系统包括：

数据结构创建单元401，用于在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

信息保存单元402，用于在所述第一动态信息数据结构中保存所述检索节点实时上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点实时上传的各个副本的当前状态信息；

判断单元403，用于根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

节点选择单元404，用于如果存在需要进行恢复的副本，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

恢复单元405，用于将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。

具体在判断是否存在需要恢复的副本时，可以有多种方式，在其中一种方式下，所述当前机器状态信息中保存有所述检索节点上传所述机器状态信息时的最近更新时间信息，所述判断单元403可以包括：

第一确定子单元，用于判断所述最近更新时间是否小于当前时间与预置的安全时间间隔的差值，如果是，则确定所述检索节点发生宕机，并将该检索节点中承载的各个副本均确定为需要进行恢复的副本。

为了避免发生误判，该系统还可以包括：

取消单元，用于在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之前，根据各个检索节点上传的各个副本的当前状态信息，查询各个副本的当前存活数量，如果存活数量等于为对应检索业务分配的副本数量，则取消对该检索节点中承载的各个副本的恢复操作。

在另一种方式下，所述判断单元403可以包括：

第二确定子单元，用于根据所述各个副本的当前状态信息，判断某正常运行的检索节点中是否存在不正常的副本，如果是，则将该不正常的副本确定为需要进行恢复的副本。具体的，如果某副本的当前状态信息中显示该副本在运行中存在错误(例如检索文件被损坏等等)，则将该副本确定为不正常的副本。

具体在进行节点选择时，需要综合机器状态以及机器中副本的状态来综合考虑，所述节点选择单元404可以包括：

过滤子单元，用于将标识为不能承载其他检索业务的检索节点、机器负载超出预置阈值的检索节点、以及正在执行副本恢复的检索节点排除；

排序子单元，用于将剩余的检索节点，从机器状态维度以及副本状态维度进行综合排序，并根据排序结果确定目标检索节点；其中，所述机器状态维度包括磁盘剩余空间、可用内存、中央处理单元CPU核心的数量以及机器负载中的一种或多种，所述副本状态维度包括当前检索节点中承载的副本数量和/或每次请求时的平均响应时间。

其中，所述排序子单元包括：

第一权重确定子单元，用于对于承载的副本数量为0的检索节点，磁盘剩余空间越大权重越高，磁盘剩余空间相等时，可用内存越大权重越高；

第二权重确定子单元，用于对于承载的副本数量不为0的检索节点，则机器负载越小权重越高，机器负载相等时，承载的副本数量越少权重越高，承载的副本数量也相等时，每次请求时的平均响应时间越短权重越高。

另外，该系统还可以包括：

优先级确定单元，用于在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之前，根据各个检索节点上传的各个副本的当前状态信息，查询各个需要进行恢复的副本的当前存活数量，根据存活数量确定各个需要进行恢复的副本的恢复优先级。

具体进行副本恢复时，需要将索引文件拷贝到目标检索节点中，而在本申请实施例中，并不是从正在运行的其他检索节点中进行拷贝，而是从Hadoop的HDFS文件系统中进行拷贝，也就是说，所述恢复单元具体可以包括：

全量索引拉取子单元，用于从存储有所有检索业务所需数据源及索引数据的文件系统中拉取最新的全量索引到所述目标检索节点中。

另外，由于检索节点上传的信息可能存在延时，因此，在判断是否存在需要恢复的副本的过程中，可能存在误判，例如，可能在对一个副本执行过恢复之后，原来的检索节点才上传上来关于该副本的信息，并且显示该副本在该检索节点中仍然处于存活状态，则此时会出现多余副本的情况，失去M*N的结构，造成系统的不稳定，为此，该系统还可以包括：

副本删除单元，用于在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之后，根据各个检索节点上传的各个副本的当前状态信息，查询所述需要进行恢复的副本的当前存活数量，如果存活数量大于为对应检索业务分配的副本数量，则将所述目标检索节点中的该副本删除。

总之，在本申请实施例中，可以抽象出一个中心节点CenterNode来实时掌控搜索平台中所有检索节点上的机器状态，以及各个检索节点上承载的所有业务的副本状态，这样，就可以根据这些状态信息来确定是否存在需要进行恢复的副本，如果存在，还可以根据机器状态信息以及副本的状态信息，来综合选择出最合适的目标检索节点，然后就可以在该节点上对副本进行恢复。可见，在本申请实施例中，在选择用于进行副本恢复的目标检索节点时，可以以各个检索节点的机器状态以及各个检索节点中各个业务副本的状态为依据，而不是进行随机选择，因此，可以在自动容灾恢复过程中，更好地保证系统的稳定性。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的集群检索平台中的自动容灾恢复方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种集群检索平台中的自动容灾恢复方法，其特征在于，所述集群检索平台包括中心节点以及用于提供检索服务的检索节点，所述方法包括：

在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

在所述第一数据结构中保存所述检索节点上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点上传的各个副本的当前状态信息；

根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

如果存在，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。

2.根据权利要求1所述的方法，其特征在于，所述当前机器状态信息中保存有所述检索节点上传所述机器状态信息时的最近更新时间信息，所述根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本包括：

判断所述最近更新时间是否小于当前时间与预置的安全时间间隔的差值，如果是，则确定所述检索节点发生宕机，并将该检索节点中承载的各个副本均确定为需要进行恢复的副本。

3.根据权利要求2所述的方法，其特征在于，在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之前，还包括：

根据各个检索节点上传的各个副本的当前状态信息，查询各个副本的当前存活数量，如果存活数量等于为对应检索业务分配的副本数量，则取消对该检索节点中承载的各个副本的恢复操作。

4.根据权利要求1所述的方法，其特征在于，所述根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本包括：

根据所述各个副本的当前状态信息，判断某正常运行的检索节点中是否存在不正常的副本，如果是，则将该不正常的副本确定为需要进行恢复的副本。

5.根据权利要求1所述的方法，其特征在于，所述根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点包括：

将标识为不能承载其他检索业务的检索节点、机器负载超出预置阈值的检索节点、以及正在执行副本恢复的检索节点排除；

将剩余的检索节点，从机器状态维度以及副本状态维度进行综合排序，并根据排序结果确定目标检索节点；其中，所述机器状态维度包括磁盘剩余空间、可用内存、中央处理单元CPU核心的数量以及机器负载中的一种或多种，所述副本状态维度包括当前检索节点中承载的副本数量和/或每次请求时的平均响应时间。

6.根据权利要求5所述的方法，所述将剩余的检索节点，从机器状态维度以及副本状态维度进行综合排序包括：

对于承载的副本数量为0的检索节点，磁盘剩余空间越大权重越高，磁盘剩余空间相等时，可用内存越大权重越高；

对于承载的副本数量不为0的检索节点，则机器负载越小权重越高，机器负载相等时，承载的副本数量越少权重越高，承载的副本数量也相等时，每次请求时的平均响应时间越短权重越高。

7.根据权利要求1所述的方法，在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之前，还包括：

根据各个检索节点上传的各个副本的当前状态信息，查询各个需要进行恢复的副本的当前存活数量，根据存活数量确定各个需要进行恢复的副本的恢复优先级。

8.根据权利要求1所述的方法，所述将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中包括：

从存储有所有检索业务所需数据源及索引数据的文件系统中拉取最新的全量索引到所述目标检索节点中。

9.根据权利要求1所述的方法，在将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中之后，还包括：

根据各个检索节点上传的各个副本的当前状态信息，查询所述需要进行恢复的副本的当前存活数量，如果存活数量大于为对应检索业务分配的副本数量，则将所述目标检索节点中的该副本删除。

10.一种集群检索平台中的自动容灾恢复系统，其特征在于，所述集群检索平台包括中心节点以及用于提供检索服务的检索节点，所述系统包括：

数据结构创建单元，用于在所述中心节点中生成各个检索节点的抽象，在所述检索节点的抽象中创建关于该检索节点的第一数据结构，并分别为该检索节点承载的各个副本创建第二数据结构；

信息保存单元，用于在所述第一数据结构中保存所述检索节点上传的当前机器状态信息，在各个第二数据结构中保存所述检索节点上传的各个副本的当前状态信息；

判断单元，用于根据所述当前机器状态信息和/或各个副本的当前状态信息，判断是否存在需要进行恢复的副本；

节点选择单元，用于如果存在需要进行恢复的副本，则根据所述当前机器状态信息以及各个副本的当前状态信息，为所述需要进行恢复的副本选择目标检索节点；

恢复单元，用于将所述需要进行恢复的副本对应的索引文件拷贝到所述目标检索节点中，由所述目标检索节点根据所述索引文件提供检索服务。