CN104156367A - 一种搜索引擎的扩容方法及搜索服务系统 - Google Patents

Abstract

本申请公开了一种搜索引擎的扩容方法及搜索服务系统；方法包括：为用于扩容的检索节点创建扩容任务；用于扩容的检索节点领取到扩容任务后，在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是以固定时间间隔定时导入到所述分布式文件系统中、以时间快照方式存储的源数据。本申请能够平滑地、对业务方透明地对搜索服务在线扩容。

Description

一种搜索引擎的扩容方法及搜索服务系统

技术领域

本发明涉及搜索领域，尤其涉及一种搜索引擎的扩容方法及搜索服务系统。

背景技术

对于搜索引擎而言，在线上已运行的搜索服务可能因为规模变化，导致以下2个问题：

(1)承载某Shard(搜索服务索引中的列索引)的若干台机器已经不再适用当前的查询请求量；

(2)单索引规模变大导致搜索性能下降，需要将单索引进一步切分。

要解决上述2个问题就需要提供一种扩容的方案来解决，而这种扩容的实现方案不能影响正常的线上应用，也即是说整个扩容期间对业务方使用搜索服务来说是透明的。

对于数据库，现有技术提供了一种基于一致性Hash的扩容方案。基于一致性Hash的扩容方案在确实能解决数据库数据热点和扩容方面的问题，遇到热点数据，只需要单独给这些数据更多的计算和存储资源。遇到扩容问题，只需要将老节点的数据移动到新节点即可。在数据库应用中采用一致性Hash的扩容较成熟，能有效解决热点问题、解决扩容问题。

但是该扩容方案需要迁移数据为代价，而对于将搜索引擎的数据进行迁移几乎是不可能的，因为搜索引擎的数据都是以倒排表的存储结构，并没有任何功能接口可以将索引中的数据部分倒腾出来然后迁移到一个新的机器节点上，并以新的索引结构存储下来；换句话说是索引并没有通过某种规则变化从而可以进行切分迁移的功能。所以基于一致性Hash的扩容方案在对于搜索引擎的扩容方面并不适合。

申请内容

本申请要解决的技术问题是如何平滑地、对业务方透明地对搜索服务在线扩容。

为了解决上述问题，本申请提供了一种搜索引擎的扩容方法，包括：

为用于扩容的检索节点创建扩容任务；

用于扩容的检索节点领取到扩容任务后，在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是以固定时间间隔定时导入到所述分布式文件系统中、以时间快照方式存储的源数据。

进一步地，所述为用于扩容的检索节点创建扩容任务的步骤包括：

当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务；所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；

当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务；所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积。

进一步地，所述的方法还包括：

对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；

分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果；分别将各虚拟组对应于分片号等于该虚拟组取模结果的列索引；

所述检索节点在分布式文件系统上复制最新时间点的全量索引的步骤包括：

检索节点在分布式文件系统上复制本检索节点所承载的列索引对应的虚拟组中最新时间点的各索引行。

进一步地，所述的方法还包括：

客户端节点周期性从分布式文件系统导入全量数据；

每次导入后，承载列索引的各检索节点中具有控制角色的检索节点消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；将回流到分布式文件系统上的全量索引复制到本地作为新的全量索引，将索引路径指向所述新的全量索引。

进一步地，所述的方法还包括：

客户端节点启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径；

如果该路径没生成，则客户端节点生成该路径并将自身IP以该路径的数据注册；如果该路径已生成，则判断该路径下的数据是否和自身IP一致，如果一致则该客户端节点获得执行增量、全量数据导入分布式文件系统的权限；如果不一致则监视该路径；

如果获得执行增量、全量数据导入分布式文件系统的权限的客户端节点在预定时间长度内没有任何心跳检查，则所述分布式服务框架系统删除所述路径；所有监视了该路径的客户端节点将触发一次监视者事件；所述监视者事件是指重新生成所述路径并将自身IP以该路径的数据注册。

进一步地，所述消费分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据的步骤后还包括：

用于扩容的检索节点对外发布搜索服务；

中心节点在用于扩容的检索节点发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；

在所有用于扩容的检索节点发布搜索服务成功后，中心节点将所述视图关系同步到分布式服务框架系统中；

所述分布式服务框架系统将该视图关系推送到属于该搜索服务的客户端节点。

本申请还提供了一种搜索服务系统，包括：检索节点、客户端节点、分布式文件系统；

中心节点，用于为用于扩容的检索节点创建扩容任务；

用于扩容的检索节点用于当领取到扩容任务后在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是所述客户端节点以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是所述客户端节点以固定时间间隔定时导入到所述分布式文件系统中并以时间快照方式存储的源数据。

进一步地，所述中心节点为用于扩容的检索节点创建扩容任务是指：

所述中心节点当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务，所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务，所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积。

进一步地，所述分布式文件系统用于在检索节点复制最新时间点的全量索引前，对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果；分别将各虚拟组对应于分片号等于该虚拟组的取模结果的列索引；

所述检索节点在分布式文件系统上复制最新时间点的全量索引是指：

检索节点在分布式文件系统上复制本检索节点所承载的列索引对应的虚拟组中最新时间点的各索引行。

进一步地，所述客户端节点用于周期性从分布式文件系统导入全量数据；

承载列索引的各检索节点中具有控制角色的检索节点还用于在每次客户端节点导入全量数据后，消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；将回流到分布式文件系统上的全量索引复制到本地，作为新的全量索引，将索引路径指向所述新的全量索引。

进一步地，所述的系统还包括：

分布式服务框架系统；

所述客户端节点还用于在启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径；如果该路径没生成，则生成该路径并将自身IP以该路径的数据注册；如果该路径已生成，则判断该路径下的数据是否和自身IP一致，如果一致则获得执行增量、全量数据导入分布式文件系统的权限，开始周期性从分布式文件系统导入全量数据；如果不一致则监视该路径，当该路径被删除时触发一次监视者事件；所述监视者事件是指重新生成所述路径并将自身IP以该路径的数据注册；

所述分布式服务框架系统用于当获得执行增量、全量数据导入分布式文件系统的权限的客户端节点在预定时间长度内没有任何心跳检查时删除所述路径。

进一步地，所述检索节点还用于在消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据后，对外发布搜索服务；

所述中心节点还用于在用于扩容的检索节点发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；在所有用于扩容的检索节点发布搜索服务成功后，将所述视图关系同步到所述分布式服务框架系统中；

所述分布式服务框架系统还用于将该视图关系推送到属于该搜索服务的客户端节点。

本申请的至少一种备选方案针对一致性Hash不适合搜索引擎扩容的短板，实现了基于分布式框架及分布式文件系统为底层技术的搜索引擎的在线扩容方案，可以随时根据业务情况及时地对业务的搜索引擎进行扩容，同时整个扩容过程将不会对线上造成任何影响，对于用户是透明的。本申请的一个优选方案通过采用虚拟组，简化了水平扩容的操作，并且可以提高稳定性及索引的查询性能。当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有优点。

附图说明

图1a是导入任务的示意图；

图1b是全量数据导入和增量数据导入的示意图；

图2是索引管理模型的示意图；

图3a是全量索引生成及回流的示意图；

图3b是全量索引的切换示意图；

图4是例子中搜索服务最初的视图关系示意图；

图5是图4中的搜索服务垂直扩容后的视图关系示意图；

图6是图5中的搜索服务水平扩容后的视图关系示意图；

图7是垂直扩容的示意图；

图8是垂直扩容的流程示意图；

图9是水平扩容的示意图；

图10是水平扩容的原理示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一、一种搜索引擎的扩容方法，包括：

为用于扩容的检索节点创建扩容任务；

用于扩容的CoreNode(检索节点)领取到扩容任务后在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是以固定时间间隔定时导入到所述分布式文件系统中、以时间快照方式存储的源数据。

本实施例中，所述分布式文件系统可以但不限于为HDFS(HadoopDistributed File System，分布式系统基础架构Hadoop的分布式文件系统)，这是一个具有高容错性、高吞吐量、可存储超大数据集的分布式文件系统。

本实施例中，所有搜索服务的数据基于两种类型导入到分布式文件系统以特殊的路径存储起来；一种是增量数据，另一种是全量数据。

增量数据是基于时间快照的，以固定时间间隔定时触发一次导入任务将源数据导入到分布式文件系统中进行存储，每次导入任务都是以当前时间为结束时间、上次导入任务的结束时间(即上次导入任务的时间区间的离当前较近的一个端点)为开始时间来确定本次导入任务的时间区间，整个系统最早的导入任务的起始时间为搜索服务开始的时刻。如图1a所示，比如一天当中第一次导入任务的起始时间为当天的00:00，结束时间为00:10；第二次导入任务的起始时间为第一次导入任务的结束时间，即00:10，结束时间为00:20；第三次导入任务的起始时间为第二次导入任务的结束时间，即00:20，结束时间为00:30；以此类推。

这样每个时间区间内的源数据将会依次以导入任务的方式定时的导入到分布式文件系统中；同时为了标识具体搜索服务具体时间区间的增量数据，可以按照特定的分区路径格式进行存储，例如，两个单Shard的搜索服务在2013年1月15日00:00:00和00:10:00的增量数据的路径如下：

搜索服务A的增量数据：

/search4A/incr/0/20130115000000/search4A

/search4A/incr/0/20130115001000/search4A

搜索服务B的增量数据：

/search4B/incr/0/20130115000000/search4B

/search4B/incr/0/20130115001000/search4B

如果是两个各有两个Shard的搜索服务，则增量数据的路径如下。

搜索服务A的增量数据：

/search4A/incr/0/20130115000000/search4A

/search4A/incr/0/20130115001000/search4A

/search4A/incr/1/20130115000000/search4A

/search4A/incr/1/20130115001000/search4A

搜索服务B的增量数据：

/search4B/incr/0/20130115000000/search4B

/search4B/incr/0/20130115001000/search4B

/search4B/incr/1/20130115000000/search4B

/search4B/incr/1/20130115001000/search4B

这样在分布式文件系统上就能定位到任何搜索服务、任何Shard、任何时间区间的源数据文件了。当然，实际应用时也可以采用路径之外的其它方式标识具体搜索服务、具体时间区间的增量数据。

全量数据的含义是一份业务方完整的待做索引的源数据。之所以需要全量数据主要有两个原因：

首先，索引会因为不断有增量的变更，而频繁的变更会引起索引结构的变化，最终导致索引性能下降，所有需要一份结束于某个时间点的全量数据来重建索引从而让索引恢复最佳性能。

其次，索引增量的变更可能因为某种原因导致丢失数据，例如：导入失败、消费异常等，所以利用一份全量源数据来重建索引也能将异常情况丢失的数据重新补偿回来。

所以在分布式文件系统中将会保存基于全量周期为间隔的源数据，即全量数据；例如，全量周期为24小时，单Shard的搜索服务A在2013年1月14日和2013年1月15日以00:00:00为结束时间点的全量数据在分布式文件系统的存储路径为：

/search4A/all/0/20130114000000/search4A

/search4A/all/0/20130115000000/search4A

两份文件分别表示结束于20130114000000和20130115000000时间点的Shard为0的全量数据。

如果是2个Shard的情况，搜索服务A在2013年1月14日和2013年1月15日以00:00:00为结束时间点的全量数据在分布式文件系统上的存储路径为：

/search4A/all/0/20130114000000/search4A

/search4A/all/0/20130115000000/search4A

/search4A/all/1/20130114000000/search4A

/search4A/all/1/20130115000000/search4A

上述文件分别表示结束于20130114000000和20130115000000时间点的Shard为0和1的全量数据。

基于上述存储路径，在分布式文件系统上就能定位到任何搜索服务、任何Shard、任何时间点的全量数据了。当然，实际应用时也可以采用路径之外的其它方式标识全量数据。

在全量数据导入和对全量数据构建索引(即：消费全量数据)的这段时间内，搜索服务的增量更新并没有暂停，那么就面临一个问题，如图1b所示，全量数据是00:00:00之前的全部数据，全量数据的导入加消费将在01:00:00完成，而这一个小时内其实每隔10分钟都进行了一次增量数据的导入和消费，那么也就意味着其实在01:00:00这个时间点做完的全量索引只是包含00:00:00这个时间点之前的数据。如果将该全量索引切换替换老索引后，这个正在运行的索引只能搜索到00:00:00之前的全部数据。面临这个问题，只能在新老索引切换完毕后马上补偿消费00:00:00后，01:00:00之前所有的增量数据，这样才能最终让索引中的数据完整，而这个过程就是全量后的增量补偿。

整个全量过程的增量数据在分布式文件系统上都以时间快照的方式存在，并不需要业务方重新导入，对应检索节点需要做的事情就是消费以下六个增量文件即可：

/search4xx/mcr/0/20130115000500/search4xx；

/search4xx/incr/0/20130115001500/search4xx；

/search4xx/incr/0/20130115002500/search4xx；

/search4xx/incr/0/20130115003500/search4xx；

/search4xx/incr/0/20130115004500/search4xx；

/search4xx/incr/0/20130115005500/search4xx。

本实施例的一种备选方案中，所述为用于扩容的检索节点创建扩容任务的步骤具体可以包括：

当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务(后文称为垂直扩容)；所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；比如扩容前有三个Shard，新增加两个副本，则用于扩容的CoreNode的个数为3×2＝6；

当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务(后文称为水平扩容)；所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积；比如扩容前Shard有三个副本；新增加两个Shard，则用于扩容的CoreNode的个数为2×3＝6。

该备选方案的一种实施方式中，所述方法还可以包括：

S201、对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；

S202、分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；

S203、分别将每个虚拟组的组号对于Shard的总个数取模，得到各虚拟组的取模结果；

S204、分别将各虚拟组对应于分片号等于该虚拟组取模结果的Shard。

当Shard个数发生变化时(比如扩容任务是增加Shard的个数)，根据最新的Shard个数再次进行步骤S203和S204。

所述CoreNode在分布式文件系统上复制最新时间点的全量索引的步骤具体可以包括：

CoreNode在分布式文件系统上复制本CoreNode所承载的Shard对应的虚拟组中最新时间点的各索引行。

虚拟组的总个数可预先设置，通常设置为2的幂次方。可以将一个虚拟组中所有的索引行作为一个子索引；整个索引管理模型如图2所示，分别承载两个Shard的CoreNode中的SolrCore(引擎抽象)分别为SolrCore-0、SolrCore-1；如果是原生Solr技术架构下，SolrCore-0、SolrCore-1分别管理一份索引即Index-0和Index-1。采取上述虚拟组后，Index-0和Index-1(比如虚拟组个数为4，索引行的唯一键为1～16)重新划分为子索引SubIndex-0(包含索引行4、8、12、16)、SubIndex-1(包含索引行1、5、9、13)、SubIndex-2(包含索引行2、6、10、14)，SubIndex-3(包含索引行3、7、11、15)；SolrCore-0管理SubIndex-0、SubIndex-2，SolrCore-1管理SubIndex-1、SubIndex-3。

这样可以在单个SolrCore下面管理按照规则切分的若干子索引，通过这种预分配虚拟组之后带来的好处有：

(1)全量切换存在新老索引并存情况，导致系统资源消耗达到峰值，从而导致FULL GC(全量垃圾回收)频繁，影响正常查询服务，有了虚拟组后，索引切换将变成子索引一个个的切换，从而让资源消耗不在存在峰值，避免FULLGC导致的服务不稳定情况。

(2)有些带唯一建的查询通过虚拟组的二次路由直接定位到子索引上，这样会比查一整块大索引性能更好。

采用了虚拟组的索引管理后，为搜索引擎的扩容提供了技术基础，即让搜索服务实例在增加Shard的情况下可避免重做索引的环节，将整个扩容过程简化为直接从分布式文件系统复制属于对应虚拟组的索引即可。另外在全量过程中能以小索引为粒度构建索引，这将会极大提高构建索引的速度。

本实施例的一种备选方案中，所述方法还可以包括：

客户端节点周期性从分布式文件系统导入全量数据；

每次导入后，承载列索引的各检索节点中具有控制角色的检索节点消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；检索节点将回流到分布式文件系统上的全量索引复制到本地作为新的全量索引，将索引路径指向所述新的全量索引。

以上步骤是全量索引的构建过程，基于搜索服务的全量索引构建包括全量索引生成、回流、切换，是整个扩容过程中的技术支撑基础。

一个具体的例子中，全量索引生成及回流的过程如图3a所示，包括步骤S301～S305。

步骤S301、每个搜索服务的ClientNode(客户端节点)通过TriggerServer(触发服务)设定的全量任务时间周期性的从分布式文件系统(本例子中为HDFS)导入全量数据。

步骤S302、ClientNode通知每个Shard中具有Master(控制)角色的CoreNode进行全量任务提交。

步骤S303、具有Master角色的CoreNode通过SolrCore(引擎抽象)A将全量任务提交给JobNode(工作节点)；SolrCore的索引路径指向索引A。

步骤S304、JobNode将CoreNode提交的任务上下文以Task(任务)形式分配给最空闲的TaskNode(任务节点)。

步骤S305、TaskNode根据此次任务上下文知道该构建索引任务的Schema(模式)在HDFS上的位置，将其复制到本地并加载；根据该Schema定义的索引结构，一行一行消费HDFS某个时间点的全量数据，如：

/search4XXX/all/0/20130114000000/search4XXX的源数据。

当该源数据全部消费完毕后，TaskNode将本地生成完毕的索引以存储路径为/search4xxx/all/0/output/20130114000000/index回流到HDFS上。

回流后进入全量索引切换的过程，如图3b所示，包括步骤S306～S308。

步骤S306、TaskNode将任务执行成功标识返回给JobNode，JobNode将成功标识返回给CoreNode。

步骤S307、CoreNode知道全量任务已经成功结束，接下来就将HDFS上/search4xxx/all/0/output/20130114000000/index的全量索引复制到本地。

步骤S308、ClientNode请求进入新的SolrCore(引擎抽象)；CoreNode创建新的SolrCore对象(图3b中的SolrCore B)，同时索引路径指向新的全量索引的地址，最后用对应新索引(图3b中的索引B)的SolrCore对象替换正在运行中的SolrCore对象，至此完成一次全量索引的构建。

本备选方案中，业务方的搜索服务部署在一个包含若干台ClientNode的集群中，如果每台ClientNode都进行增量、全量数据导入分布式文件系统的工作，那么分布式文件系统中会存在多份重复数据，如果部署只有一台ClientNode进行导入，那么该ClientNode出现宕机后，导入任务将会终止。为了保证执行导入的ClientNode只有一台、并且在该ClientNode出现宕机后将有其他ClientNode顶替继续执行增、全量导入分布式文件系统的任务，本实施例采用分布式锁来解决。

本备选方案的一种实施方式中，所述方法还可以包括：

ClientNode启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径，如：/search4xxx/dump/；

如果该路径没生成，则生成该路径并将自身IP以该路径的data(数据)注册；如果该路径已生成，则判断该路径下的data是否和自身IP一致，如果一致则获得执行增量、全量数据导入分布式文件系统的权限，开始周期性从分布式文件系统导入全量数据；如果不一致则监视该路径；

如果获得执行增量、全量数据导入分布式文件系统的权限的ClientNode在预定时间长度内没有任何心跳检查，则所述分布式服务框架系统删除所述路径；所有watch(监视)了该路径的ClientNode将触发一次watcher(监视者)事件；所述watcher事件是指重新生成所述路径并将自身IP以该路径的data注册。

整个生成和注册过程是一个原子过程，多个客户端的连接并不能同时对同一个路径进行生成和注册。这样经过启动过程中类似抢锁的过程就能唯一确定一台ClientNode具有执行增量、全量数据导入分布式文件系统的任务的权限。

该协调过程可利用分布式服务框架系统中分布式锁的特性来实现。在分布式服务框架系统(比如但不限于Zookeeper)上生成的/search4xxx/dump/路径并不是一个持久化的路径，如果生成该路径的这台ClientNode在预定时间长度(可以但不限于为一个分布式服务框架系统Session(会话)周期)内没有任何心跳检查过来，分布式服务框架系统将认为该ClientNode已经宕机，并将/search4xxx/dump/路径的/dump/删除。删除动作一旦发生，所有watch了/search4xxx/dump/的ClientNode将触发一次watcher事件，该事件的主要动作变是重新开始生成/search4xxx/dump/，并将IP注册上去。这样通过一番重新的“抢锁”动作，就会有新的ClientNode重新获得执行增量、全量的导入权限。

在每个搜索服务的M*N索引分布模型中，用于承载每个Shard的副本的多个CoreNode中，有一个CoreNode具有Master角色，具有Master角色的CoreNode将负责该Shard的全量索引任务的提交和通知其他Slave(从属)节点到分布式文件系统上复制指定路径的全量索引。而Master角色的协调和上文中“执行增量、全量数据导入分布式文件系统的权限”的协调过程基本类似，也是利用了分布式锁的特性来实现，在这里不再详述其实现细节。

本实施例的一种备选方案中，所述消费分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据的步骤后，还可以包括：

用于扩容的CoreNode对外发布搜索服务；

更新客户端的视图关系。

该备选方案的一种实施方式中，所述更新客户端的视图关系的步骤具体包括：

中心节点在用于扩容的CoreNode发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；

在所有用于扩容的CoreNode发布搜索服务成功后，中心节点将所述视图关系同步到分布式服务框架系统中；

分布式服务框架系统将该视图关系推送到属于该搜索服务的客户端节点。

该实施方式中，所述分布式服务框架系统可以但不限于为Zookeeper，Zookeeper是Hadoop的正式子项目，是一个基于Fast Paxos算法实现的为大型分布式系统提供系统间协调、配置维护、名字服务、Leader选举、分布式锁同步、队列管理等服务的一个分布式服务框架系统。

CenterNode(中心节点)在发布具体搜索服务后，将会在自己内存结构中保存一份该搜索服务分布的M*N视图关系，并在第一次全量成功并发布搜索服务后将该视图关系同步到Zookeeper中。而属于该搜索服务的ClientNode将会由Zookeeper推送该视图关系到本机，这样每台机器就能知道需要发起查询的搜索引擎有几个Shard，每个Shard有几个副本CoreNode了。一个具体例子中，搜素服务最初的视图关系如图4所示，一个名为search4XXX的搜索服务被分成3个Shard(图4中的“0”、“1”、“2”)，每个Shard有2个索引副本分别部署在不同地址的CoreNode上，图4中Shard“0”部署在地址为IP0-1和IP0-2的CoreNode上，Shard“1”部署在地址为IP1-1和IP1-2的CoreNode上，图4中Shard“2”部署在地址为IP2-1和IP2-2的CoreNode上。通过该搜索引擎视图关系，ClientNode就能知道将搜索请求发送到具体承载着索引的机器节点上去进行检索，同时也知道自己将分几个Shard进行数据导入。

上述的视图关系并不是一成不变，当发生垂直扩容(各Shard副本增加)后，Zookeeper会将最新的视图关系推送到ClientNode，如图5所示，服务端通过垂直扩容后，每个Shard从两个副本变成了三个，而三个Shard新增的副本分别部署在地址为IP0-3、IP1-3、IP2-3的CoreNode节点上。当Zookeeper将这份新的视图推送到ClientNode后，ClientCore就能将部分请求负载均衡后发送到地址为IP0-3、IP1-3、IP2-3的CoreNode节点上去，这样垂直扩容的目的即达到，而整个扩容的过程对ClientNode节点完全透明，ClientNode只会根据视图关系来定位请求发送而已，而新的视图推送的前提是整个垂直扩容正常完成，才会有推送发生。

同理当如图5所示的视图关系代表的搜索服务发生水平扩容(增加Shard)后，该视图关系将会如图6所示，该视图关系说明搜索服务search4XXX完成了一次Shard从3个变为4个的水平扩容，新Shard(图6中的“3”)的所有副本分别部署在地址为IP3-1、IP3-2、IP3-3的CoreNode中。当该视图关系被推送到ClientNode，代表一个水平扩容成功完成，业务方可以通过新的视图关系发送搜索请求，同时也能根据新的Shard数进行Shard的数据导入了。

图6所示的是水平扩容的实施方式之一；如果采取上文中虚拟组的方式进行水平扩容，则扩容前后Shard的个数需为2的幂次方，例如原先为2个Shard，扩容时增加2个，扩容后共有4个Shard；再比如原先为4个Shard，扩容时增加4个shard，扩容后共有8个Shard。

本实施例中，可以根据引擎的一个或多个指标的分析来决定搜索服务是否需要进行扩容。例如，如果是请求量的增加，导致当前CoreNode节点无法承载，那么就需要进行垂直扩容。如果是索引规模变大，导致单次请求平均响应变慢越过设定阈值，那么就需要进行水平扩容。所述一个或多个指标参数可以包括以下任一个或任一组合：索引容量、索引数据量、机器Load、单次请求平均响应时间、平均每秒响应多少请求等；这些指标可通过CenterNode实时收集上来通过ManagerNode(管理节点)进行可视化展示；从页面上管理员可以及时的观察到具体搜索服务的搜索指标数据，然后决定是否需要进行垂直/水平扩容；也可以由ManagerNode根据预定规则判断指标是否符合垂直/水平扩容的条件，如果决定扩容或符合条件，则通知所述CenterNode开始扩容。

扩容过程中将涉及到多台CoreNode的SolrCore创建、复制分布式文件系统上的索引数据、发布搜索服务、推送新的索引视图关系几个阶段的动作。每个阶段的动作必须等全部用于扩容的CoreNode成功完成，并且CenterNode收集到每台用于扩容的CoreNode上报的成功标识后，通知用于扩容的CoreNode继续下阶段动作，如果任何一台CoreNode执行当前阶段动作失败，该CoreNode立即将当前阶段的执行状态汇报给CenterNode，CenterNode将根据当前状态，通过人工参与或自动的方式执行暂停、结束或者回滚扩容动作。综上所述，CenterNode在在线扩容过程中的指标收集和协调将是一个非常关键的因素。

下面用两个具体的例子进一步说明本实施例；这两个例子中搜索引擎的索引分布为M*N模型，分布式文件系统为HDFS，分布式服务框架系统为Zookeeper；第一个例子说明垂直扩容时的过程；第二个例子说明水平扩容时的过程。

第一个例子是垂直扩容，目标是将具体搜索服务对应引擎中每个Shard添加若干个副本，如图7所示，Shard1扩容前有3个CoreNode副本(检索节点1-1、检索节点1-2、检索节点1-3)，经过垂直扩容后有4个CoreNode副本(检索节点1-1、检索节点1-2、检索节点1-3、检索节点1-4)。当这个过程成功完成后，CenterNode将会将更新Zookeeper该搜索服务的视图关系，即某个Shard下添加一个新的CoreNode的IP，Zookeeper的视图关系发生变化，业务方的ClientNode马上会感知该变化，进而更新最新引擎视图关系，这样所有的业务方ClientNode就能将请求发送到新添加的CoreNode1-4上了。

整个垂直扩容的过程如图8所示，包括如下的步骤S801～S808。

S801、CenterNode通过集群中CoreNode的heartbeat(心跳信息)收集到所有CoreNode当时的状态信息，例如：是否已经承载了SolrCore，是否较空闲。管理员通过ManagerNode能够实时看到整个集群中的CoreNode的状态信息，如果需要对某个具体搜索服务进行垂直扩容，只需要为该搜索服务选择当前状态较空闲的CoreNode(一般是未部署任何搜索引擎的CoreNode)，然后点击垂直扩容指令。

S802、CenterNode收到扩容指令后，知道该扩容涉及的具体CoreNode是哪几台CoreNode，那么将创建一个垂直扩容的Task(任务)放入任务池中，那些被选中的用于扩容的CoreNode(比如图8中的检索节点A)通过一次heartbeat后将领取到垂直扩容的Task。

S803、CoreNode领取到垂直扩容的Task后，首先创建一个引擎对象SolrCore(比如图8中的引擎抽象A)，创建SolrCore完毕后，将创建成功标识信息回馈给CenterNode。

S804、CenterNode收集到所有用于扩容的CoreNode反馈的创建成功标识信息后，创建索引复制的Task放入任务池中，以通知该批CoreNode进行索引复制工作。如果出现某台CoreNode创建SolrCore失败将暂停扩容任务，并将错误信息通过ManagerNode展现给操作人员，操作人员分析具体错误原因，如果发现是配置文件问题，则更新配置，对存在问题的CoreNode发送重建指令，如果是CoreNode的问题，可以重新选择其它的CoreNode进行创建，即重新执行步骤S803。

S805、CoreNode如果领取到索引复制的Task，证明创建SolrCore过程肯定成功完成，那么CoreNode到HDFS上复制最新时间点的全量索引，之后开始补偿消费这个最新时间点后、到当前时间点为止的所有的增量数据。整个过程完毕后CoreNode将复制成功标识反馈给CenterNode。

S806、CenterNode收集到所有用于扩容的CoreNode反馈的复制成功标识后，将通知该批CoreNode进行搜索服务发布工作。当然如果出现了复制全量索引和补偿消费增量数据出现失败的信息反馈，CenterNode将会暂停扩容任务，并将错误信息通过ManagerNode展现给操作人员，操作人员分析具体错误原因后，选择存在问题的CoreNode重新进行复制全量索引或者重新补偿消费增量数据的操作，即重新执行步骤S805。

S807、CoreNode领取到发布搜索服务的Task，证明复制全量索引和补偿消费增量数据的任务肯定成功完成，那么CoreNode开始对外发布搜索服务，同时将发布搜索服务的成功标识反馈给CenterNode。这个时候CoreNode虽然发布搜索服务了，但是并不会有流量进来，因为客户端ClientNode还没感知到最新的视图关系。

S808、CenterNode收集到所有用于扩容的CoreNode发布搜索服务的成功标识后，将该搜索服务最新的视图关系同步到Zookeeper，Zookeeper更新视图关系后，客户端ClientNode节点马上更新自身的搜索引擎的视图关系，那么最新的搜索请求就可以进到那些扩容成功的CoreNode上了。当然如果CoreNode反馈的是发布搜索服务失败标识，那么CenterNode将会暂停扩容任务，并将错误信息通过ManagerNode展示给操作人员，操作人员分析具体错误原因后，选择存在问题的CoreNode重新进行发布搜索服务的操作，即重新执行步骤S807。

当步骤S808成功完成后，可能会出现扩容出来的CoreNode上的索引仍然出现查询异常的情况，那么通过ManagerNode，管理员可以让CenterNode执行回滚操作，让该搜索服务恢复到扩容前的状态。首先更新CenterNode的视图关系，即将每个Shard下新扩容的CoreNode从视图关系中删除，然后同步最新的视图关系到Zookeeper；Zookeeper更新该视图关系后，客户端ClientNode马上能感知到自身搜索引擎最新视图关系那么ClientNode的搜索请求将不会把请求再发送到那些扩容的CoreNode上。至此，完成了整个垂直扩容的回滚操作。

第二个例子是水平扩容，目标是在原来Shard的基础上增加新的Shard，比如之前是1个Shard，现在升级成2个Shard，如图9所示，扩容前只有Shard1，有4个CoreNode副本(检索节点1-1、检索节点1-2、检索节点1-3、检索节点1-4)，经过水平扩容后新增了har2，也有4个CoreNode副本(检索节点2-1、检索节点2-2、检索节点2-3、检索节点2-4)。

本例子中采取了索引预分片的虚拟组技术，那么搜索引擎的水平扩容其实就简化到和垂直扩容基本一致，其实现原理如图10所示：

后台选择用于扩容的CoreNode(图10中的CoreNode C、CoreNode D)，提交一个由2个Shard(图10中的CoreNode A、CoreNode B)变成4个Shard的水平扩容指令到CenterNode。其中，原先2个Shard引擎抽象分别为SolrCore-0、SolrCore-1；SolrCore-0对应的子索引分别为SubIndex-0和SubIndex-2，SolrCore-1对应的子索引分别为SubIndex-1和SubIndex-3；在所述CoreNode C、CoreNode D上将会分别创建SolrCore-2、SolrCore-3的搜索服务实例(同垂直扩容一致)，CenterNode接受到实例创建成功的反馈后，接下来只需要通知SolrCore-2、SolrCore-3到HDFS下复制对应搜索服务实例的子索引(SubIndex-2和SubIndex-3)的各行索引数据(图10中分别为唯一键是2、6、10、14的索引行、及唯一键是3、7、11、15的索引行)到本地即可。

水平扩容的详细执行过程如下，包括步骤S901～S906。

S901、CenterNode通过集群中CoreNode的heartbeat收集到所有CoreNode当时的状态信息，例如：是否已经承载了SolrCore，是否较空闲。管理员通过ManagerNode能够实时看到整个集群中CoreNode的状态信息，如果需要对某个具体搜索服务进行水平扩容，只需要为该搜索服务需要增加的Shard数选择当前状态较空闲的CoreNode(一般是未部署任何搜索引擎的CoreNode)。例如，当前搜索服务的Shard个数为1，并且副本数为4，现在想扩容为Shard为2(即增加一个Shard)，那么需要选择出4台新的CoreNode作为新Shard的SolrCore的承载节点。选择好用于扩容的CoreNode后，管理员在ManagerNode触发水平扩容指令。

S902、CenterNode接收到ManagerNode提交的水平扩容指令后，知道该水平扩容涉及的新Shard需要的CoreNode是哪几台，CenterNode将创建一个水平扩容的Task放入新Shard下所有CoreNode归属的任务池中，那些被选中的新Shard中用于扩容的CoreNode通过一次heartbeat后将领取到水平扩容的Task。

S903、用于扩容的CoreNode领取到水平扩容Task后，首先创建一个引擎对象SolrCore，创建SolrCore完毕后，将创建成功标识信息回馈给CenterNode。如果用于扩容的某台CoreNode创建SolrCore失败，CenterNode将暂停扩容任务，并将错误信息通过ManagerNode展现给操作人员，操作人员分析具体错误原因，如果发现是配置文件问题，则更新配置，对存在问题的CoreNode发送重建指令，即由该CoreNode重新执行步骤S902；如果是CoreNode本身的问题，可以重新选择CoreNode进行创建，即由新选择的CoreNode执行步骤S902。

S904、CenterNode收集到所有用于扩容的CoreNode反馈的创建成功标识信息后，将提交同步索引任务到新Shard下所有CoreNode归属的任务池中，以通知该搜索服务下新Shard下所有的CoreNode从HDFS中复制属于本CoreNode所承载的Shard对应的子索引，例如：SolrCore-2复制SubIndex-2，SolrCore-3复制SubIndex-3；复制成功后反馈复制索引成功标识给CenterNode。如果用于扩容的某台CoreNode复制子索引失败，CenterNode将暂停扩容任务，并将错误信息通过ManagerNode展现给操作人员，操作人员分析具体错误原因，可以重新触发同步索引任务，即重新执行步骤S904。

S905、CenterNode接收到所有用于扩容的CoreNode反馈的复制索引成功标识后，提交补偿增量任务到新Shard下所有CoreNode归属的任务池中，新Shard中所有CoreNode通过一次heartbeat后将领取到补偿增量的Task；补偿成功后反馈补偿消费成功标识给CenterNode。如果用于扩容的某台CoreNode补偿增量任务失败，CenterNode将暂停扩容任务，并将错误信息通过ManagerNode展现给操作人员，操作人员分析具体错误原因，可以重新触发补偿增量任务，即重新执行步骤S905。

S906、CenterNode接收到所有用于扩容的CoreNode反馈的补偿消费成功标识后，将提交发布检索服任务到新Shard下所有CoreNode归属的任务池中(老Shard下的CoreNode已经发布过检索服务，所以老Shard下的CoreNode的不需要重新发布)。所有用于扩容的CoreNode通过一次heartbeat后将领取到检索服务发布的Task；发布检索服务成功后发布成功标识给CenterNode。如果用于扩容的某台CoreNode发布检索服务失败，那么CenterNode将会暂停扩容任务，并将错误信息通过ManagerNode展示给操作人员，操作人员分析具体错误原因后，选择存在问题的CoreNode重新进行检索服务发布，即重新执行步骤S906。

S907、CenterNode收集到所有用于扩容的CoreNode反馈的发布成功标识后，将该搜索服务最新的视图关系同步到Zookeeper，Zookeeper更新视图关系后，客户端ClientNode节点马上更新自身的搜索引擎的视图关系，这个时候SolrCore-0和SolrCore-1管辖下的SubIndex-2和SubIndex-3(图10中的虚线箭头)将不会再有请求进来，所有针对SubIndex-2和SubIndex-3的索引都将会进入SolrCore-2和SolrCore-3的节点，针对SubIndex-0和SubIndex-1的索引则依然分别进入SolrCore-0和SolrCore-1的节点(图10中分别为唯一键是4、8、12、16的索引行、及唯一键是1、5、9、13的索引行)，至此整个水平扩容完成。

本例子中，也可以不采用虚拟组的做法；在复制全量索引时，需要重做索引，分别将各索引行的唯一键对扩容后总的Shard数取模，计算结果即该索引行所属于的Shard的分片号；这样原先的全量索引就被均匀消费成多个Shard的全量索引；补偿消费增量数据时的做法类似，也是将各行增量数据分到不同的Shard中。这样也能实现水平扩容。

实施例二，一种搜索服务系统，包括：

检索节点、客户端节点、分布式文件系统；

中心节点，用于为用于扩容的检索节点创建扩容任务；

用于扩容的检索节点用于当领取到扩容任务后在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是所述客户端节点以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是所述客户端节点以固定时间间隔定时导入到所述分布式文件系统中、以时间快照方式存储的源数据。

本实施例的一种备选方案中，所述中心节点为用于扩容的检索节点创建扩容任务是指：

所述中心节点当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务，所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务，所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积。

在另一备选方案中，所述搜素服务系统中还可以包括一管理节点，用于供管理员下达扩容指令及选择用于扩容的检索节点；所述中心节点根据所述扩容指令为被选择的检索节点创建相应的扩容任务。

本实施例的一种备选方案中，所述分布式文件系统可以用于在检索节点复制最新时间点的全量索引前，对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果；分别将各虚拟组对应于分片号等于该虚拟组的取模结果的列索引；

当Shard个数发生变化时(比如扩容任务是增加Shard的个数)，所述分布式文件系统需根据最新的Shard个数再次进行“分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果”及“分别将各虚拟组对应于分片号等于该虚拟组的取模结果的列索引”的操作。

该备选方案中，所述检索节点在分布式文件系统上复制最新时间点的全量索引具体可以是指：

检索节点在分布式文件系统上复制本检索节点所承载的列索引对应的虚拟组中最新时间点的各索引行。

本实施例的一种备选方案中，所述客户端节点还可以用于周期性从分布式文件系统导入全量数据；

承载列索引的各检索节点中具有控制角色的检索节点还用于在每次客户端节点导入全量数据后，消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；将回流到分布式文件系统上的全量索引复制到本地，作为新的全量索引，将索引路径指向所述新的全量索引。

本实施例的一种备选方案中，所述的系统还包括：

分布式服务框架系统；

所述客户端节点还可以用于在启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径；如果该路径没生成，则生成该路径并将自身IP以该路径的数据注册；如果该路径已生成，则判断该路径下的数据是否和自身IP一致，如果一致则获得执行增量、全量数据导入分布式文件系统的权限，开始周期性从分布式文件系统导入全量数据；如果不一致则监视该路径，当该路径被删除时触发一次监视者事件；所述监视者事件是指重新生成所述路径并将自身IP以该路径的数据注册；

所述分布式服务框架系统用于当获得执行增量、全量数据导入分布式文件系统的权限的客户端节点在预定时间长度内没有任何心跳检查时删除所述路径。

本实施例的一种备选方案中，所述检索节点还可以用于在消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据后，对外发布搜索服务；

所述中心节点还可以用于在用于扩容的检索节点发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；在所有用于扩容的检索节点发布搜索服务成功后，将所述视图关系同步到所述分布式服务框架系统中；

所述分布式服务框架系统还可以用于将该视图关系推送到属于该搜索服务的客户端节点。

其它实施细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。

Claims (12)

1.一种搜索引擎的扩容方法，包括：

为用于扩容的检索节点创建扩容任务；

用于扩容的检索节点领取到扩容任务后，在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是以固定时间间隔定时导入到所述分布式文件系统中、以时间快照方式存储的源数据。

2.如权利要求1所述的方法，其特征在于，所述为用于扩容的检索节点创建扩容任务的步骤包括：

当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务；所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；

当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务；所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积。

3.如权利要求1所述的方法，其特征在于，还包括：

对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；

分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果；分别将各虚拟组对应于分片号等于该虚拟组取模结果的列索引；

所述检索节点在分布式文件系统上复制最新时间点的全量索引的步骤包括：

检索节点在分布式文件系统上复制本检索节点所承载的列索引对应的虚拟组中最新时间点的各索引行。

4.如权利要求1所述的方法，其特征在于，还包括：

客户端节点周期性从分布式文件系统导入全量数据；

每次导入后，承载列索引的各检索节点中具有控制角色的检索节点消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；将回流到分布式文件系统上的全量索引复制到本地作为新的全量索引，将索引路径指向所述新的全量索引。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

客户端节点启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径；

如果该路径没生成，则客户端节点生成该路径并将自身IP以该路径的数据注册；如果该路径已生成，则判断该路径下的数据是否和自身IP一致，如果一致则该客户端节点获得执行增量、全量数据导入分布式文件系统的权限；如果不一致则监视该路径；

如果获得执行增量、全量数据导入分布式文件系统的权限的客户端节点在预定时间长度内没有任何心跳检查，则所述分布式服务框架系统删除所述路径；所有监视了该路径的客户端节点将触发一次监视者事件；所述监视者事件是指重新生成所述路径并将自身IP以该路径的数据注册。

6.如权利要求1到5中任一项所述的方法，其特征在于，所述消费分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据的步骤后还包括：

用于扩容的检索节点对外发布搜索服务；

中心节点在用于扩容的检索节点发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；

在所有用于扩容的检索节点发布搜索服务成功后，中心节点将所述视图关系同步到分布式服务框架系统中；

所述分布式服务框架系统将该视图关系推送到属于该搜索服务的客户端节点。

7.一种搜索服务系统，包括：检索节点、客户端节点、分布式文件系统；

其特征在于，还包括：

中心节点，用于为用于扩容的检索节点创建扩容任务；

用于扩容的检索节点用于当领取到扩容任务后在分布式文件系统上复制最新时间点的全量索引，然后消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据；所述全量索引是对全量数据所做的索引；所述全量数据是所述客户端节点以全量周期为间隔导入到所述分布式文件系统上的源数据；所述增量数据是所述客户端节点以固定时间间隔定时导入到所述分布式文件系统中并以时间快照方式存储的源数据。

8.如权利要求7所述的系统，其特征在于，所述中心节点为用于扩容的检索节点创建扩容任务是指：

所述中心节点当请求量增加，导致当前检索节点无法承载时，创建增加各列索引的副本的扩容任务，所述用于扩容的检索节点为用于承载新增副本的检索节点，个数为列索引的个数与所增加的副本个数的乘积；当索引规模变大，导致单次请求平均响应变慢时，创建增加列索引的个数的扩容任务，所述用于扩容的检索节点为用于承载新增列索引的检索节点，个数为增加的列索引个数与各列索引副本个数的乘积。

9.如权利要求7所述的系统，其特征在于：

所述分布式文件系统用于在检索节点复制最新时间点的全量索引前，对于全量索引中的各索引行，分别将各索引行的唯一键对于虚拟组的总个数取模，得到各索引行的取模结果；分别将各索引行分入组号等于该索引行的取模结果的虚拟组中；分别将每个虚拟组的组号对于列索引的总个数取模，得到各虚拟组的取模结果；分别将各虚拟组对应于分片号等于该虚拟组的取模结果的列索引；

所述检索节点在分布式文件系统上复制最新时间点的全量索引是指：

检索节点在分布式文件系统上复制本检索节点所承载的列索引对应的虚拟组中最新时间点的各索引行。

10.如权利要求7所述的系统，其特征在于：

所述客户端节点用于周期性从分布式文件系统导入全量数据；

承载列索引的各检索节点中具有控制角色的检索节点还用于在每次客户端节点导入全量数据后，消费导入的全量数据，生成全量索引并将该全量索引回流到分布式文件系统；将回流到分布式文件系统上的全量索引复制到本地，作为新的全量索引，将索引路径指向所述新的全量索引。

11.如权利要求7到10中任一项所述的系统，其特征在于，还包括：

分布式服务框架系统；

所述客户端节点还用于在启动后连接分布式服务框架系统，判断是否已生成本身所承载的搜索服务的路径；如果该路径没生成，则生成该路径并将自身IP以该路径的数据注册；如果该路径已生成，则判断该路径下的数据是否和自身IP一致，如果一致则获得执行增量、全量数据导入分布式文件系统的权限，开始周期性从分布式文件系统导入全量数据；如果不一致则监视该路径，当该路径被删除时触发一次监视者事件；所述监视者事件是指重新生成所述路径并将自身IP以该路径的数据注册；

所述分布式服务框架系统用于当获得执行增量、全量数据导入分布式文件系统的权限的客户端节点在预定时间长度内没有任何心跳检查时删除所述路径。

12.如权利要求11所述的系统，其特征在于：

所述检索节点还用于在消费所述分布式文件系统中从所述最新时间点开始、到当前时间点为止的所有增量数据后，对外发布搜索服务；

所述中心节点还用于在用于扩容的检索节点发布搜索服务后，保存该搜索服务分布的索引存储结构的视图关系；在所有用于扩容的检索节点发布搜索服务成功后，将所述视图关系同步到所述分布式服务框架系统中；

所述分布式服务框架系统还用于将该视图关系推送到属于该搜索服务的客户端节点。