CN106649870A - 一种搜索引擎分布式实现方法 - Google Patents

Abstract

本发明特别涉及一种搜索引擎分布式实现方法。该搜索引擎分布式实现方法，分布式集群组采用m×n模型，每一组集群内采用Master/Slave模型保证单组数据的一致性和搜索服务的可用性；索引构建采用主磁盘索引+内存索引+从磁盘索引相结合的模型，实时索引的请求先写CommitLog日志；搜索请求分为查询，更新，添加，删除4种，分别定位到分布式集群的一组或者多组服务器。该搜索引擎分布式实现方法，引入自定义多维度的分组规则构建分布式索引数据，减少了索引搜索时间，提高了搜索性能；采用内存与磁盘索引相结合的多索引机制，减少了索引合并时间开销，提升了搜索响应时间；解决了分布式环境下的索引数据容灾问题，保证了数据的一致性和可用性。

Description

一种搜索引擎分布式实现方法

技术领域

本发明涉及Web数据搜索技术领域，特别涉及一种搜索引擎分布式实现方法。

背景技术

互联网信息技术的高速发展使人们更加关注如何以最快的时间获取实效数据，并从中挖掘到有价值的信息。获取实时资讯的方法有两种：一是建立实时数据库，保证数据的强一致性(ACID)和高可用性，但其在分布式环境下的扩展能力较为有限；二是建立实时搜索引擎，不仅有理论价值，同时有重大的应用价值。

传统的信息搜索技术发展非常成熟，但是在查询精度和不同查询需求上存在许多不足，不能满足信息的实时搜索需求。实时搜索是传统搜索引擎的扩展和延伸，可以分为通用实时搜索引擎和垂直实时搜索引擎。

垂直搜索引擎针对某一领域行业的搜索，特点是专、精、深，实时搜索的研究大多集中于垂直搜索领域，如在图片搜索和物联网领域的应用。实时搜索已成为当前搜索引擎领域的热点问题，其核心概括为实时数据获取和实时索引构建两方面。

相比传统搜索研究，垂直搜索数据来源相对简单，因此垂直实时搜索的难点问题是分布式环境下的实时索引构建。实时索引构建主要指的是在大规模高并发的分布式环境下，即时提交实时数据构建索引，保证实时数据即时展示以及分布式数据的一致性和容灾。

基于此，本发明提出了一种搜索引擎分布式实现方法。

发明内容

本发明为了弥补现有技术的缺陷，提供了一种简单高效的搜索引擎分布式实现方法。

本发明是通过如下技术方案实现的：

一种搜索引擎分布式实现方法，其特征在于：由分布式m×n系统模型构建，索引数据构建和搜索功能实现3部分组成；分布式集群组采用m×n模型，每一组集群内采用Master/Slave模型保证单组数据的一致性和搜索服务的可用性；索引构建采用主磁盘索引+内存索引+从磁盘索引相结合的模型，保证最新的数据即时展现，实现搜索的实时性，实时索引的请求先写CommitLog日志，保证实时索引的数据容灾性；搜索请求分为查询，更新，添加，删除4种，分别定位到分布式集群的一组或者多组服务器。

在索引量和搜索请求增加的情况下，所述分布式m×n系统模型动态添加行列的机器数量保证存储负载和搜索性能；其中，n列指系统划分为搜索服务器集群的个数，m行指单个搜索服务器集群包含搜索服务器的台数，m≥1且n≥1。

所述分布式m×n系统模型构建过程如下：

(1)自定义切分规则

根据系统需求，设定自定义的索引切分规则进行GroupFilter分组路由，分组规则既可以是单维也可以是多维，即在m×n二维分组的基础上进行扩展，多维数组与一维数组存储机制一致；

(2)确定m×n行列值

m和n的行列值取决于搜索服务器单机负载能力和分布式系统索引总量和搜索请求总量两个因素；

(3)建立分布式集群

根据索引切分规则和m、n的行列数，建立分布式搜索服务器集群；所有搜索服务器均提供搜索服务，搜索请求随机发送到组内的任一服务器；在同一组搜索服务器集群中，每一台搜索服务器分别向组内其他服务器发布感知服务，确保两两感知；

单组服务器集群内部，设定一台主服务器，其他均为从服务器，主服务器负责主索引的建立和写CommitLog日志文件，从服务器从主服务器中同步主索引，同步CommitLog日志建立内存索引；通过Master/Slave模型保证单组的索引数据容灾性，在组内某一搜索服务器宕机的情况下保证搜索服务的可用性。

所述分布式m×n系统模型中，m、n的计算式为：n＝S/T；m＝Q/R+X；其中S为索引总量，T为单机承载索引量，Q为搜索请求总量，R为单机承载搜索请求量，X为机器增量。

所述索引数据包括主磁盘索引，内存索引，从磁盘索引3个部分；写内存索引前先写CommitLog日志，持久化索引数据，保证内存索引数据不丢失；内存索引到达阈值后刷入从磁盘索引，保证可用性；索引数据的构建采用全量dump(转储)+实时增量dump的模型构建，全量dump采用时间周期任务定期执行，实时增量dump由实时调用接口生成。

所述索引数据构建过程如下：

(1)主磁盘索引构建

(a)搜索服务器定时触发全量dump程序：系统从数据源获取索引数据；索引建立采用迭代器模型，利用DataProvider接口，首先利用hasNext()判断下一条语句是否存在，存在则用next()方法取下一条数据，构建并返回一条Map记录，直至hasNext()方法返回为false，结束整个迭代过程；Map记录对应一篇索引文档，Map的<key,value>键值对对应于文档的域和域值；利用封装好的Map对象构建Solr的AddUpdateCommand对象，最后调用Solr的UpdateHandle.addDoc()方法添加文档至索引；

(b)时间点设置：主索引构建过程开始时，记录一个时间点checkPoint；主索引建立完成后，提供搜索的服务将从旧索引替换到新索引，但是新索引建立过程中，会有增量的实时索引产生，因此需要补全在全量执行期间的增量数据，通过时间点机制从后补全实时索引；

(c)Slave服务器构建主索引：Master服务的主索引构建完成后，通知Slave服务器进行主索引的拷贝，并将checkPoint传递给Slave服务器，Slave服务器完成索引的构建工作后通知Master服务器，新的索引向外提供搜索服务；

(2)实时索引构建

(a)实时更新请求：实时请求可以与主索引同样来自于数据源，也可以来自客户端的实时接口调用；请求对象添加到CommitLog日志文件中；

(b)CommitLog日志建立：所有的实时请求都写入主服务器的CommitLog日志中，持久化索引请求；搜索服务器启动时创建实时索引的构建进程Real-timeJob，不断轮循CommitLog日志，一旦有新的记录产生即进行写索引操作，根据请求类型的不同，分别调用Solr的UpdateHandler的相应方法建立内存索引；

(c)从磁盘索引建立：当内存索引达到阈值时，新开一个内存索引，新来的实时请求写入新的内存索引，同时将旧的内存索引刷新至磁盘；利用内存索引与磁盘索引结构完全相同的特性，调用Directory的copy方法直接将内存索引拷贝至磁盘，形成从磁盘索引，提升搜索性能，实现立即搜索。

所述搜索功能实现包括查询、新增、更新、删除4种功能，查询功能操作不会修改索引数据结构，其他3种功能操作都会造成索引数据的修改，且有相应的批量操作方法。

所述搜索功能实现过程如下：

(1)搜索功能实现

用户发出搜索请求后，通过路由规则获取索引所在分布式搜索服务器组的集合；如果是单组搜索，需要对当前所有的索引进行搜索，包含主磁盘索引、内存索引、从磁盘索引，搜索结果过滤掉已被删除的文档；被删除文档的docId存储在delList集合中；多组搜索则利用Solr的shard概念对多组的结果集作合并操作；任意选定分组集中的一组，通过TCP/IP协议进行访问，此时利用Solr提供的EmbeddedSolrServer获取当前组索引，并向其他组发送TCP/IP请求，获取索引数据并进行索引的merge操作，提高索引获取速度；

(2)添加、删除、更新功能实现

(a)添加功能实现：客户端发出Add命令，将其封装成添加请求写入CommitLog日志文件中；

(b)删除功能实现：客户端发出Delete命令，将其封装成删除请求DeleteDocumentRequest写入CommitLog日志文件中；

(c)更新功能实现：与Add命令相同，客户端发出Update命令会被封装为UpdateDocumentRequest请求，写入CommitLog日志中。

本发明的有益效果是：该搜索引擎分布式实现方法，引入自定义多维度的分组规则构建分布式索引数据，减少了索引搜索时间，提高了搜索性能；采用内存与磁盘索引相结合的多索引机制，减少了索引合并时间开销，提升了搜索响应时间；解决了分布式环境下的索引数据容灾问题，保证了数据的一致性和可用性。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚明白，以下结合实施例，对本发明进行详细的说明。应当说明的是，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

该搜索引擎分布式实现方法，由分布式m×n系统模型构建，索引数据构建和搜索功能实现3部分组成；分布式集群组采用m×n模型，每一组集群内采用Master/Slave模型保证单组数据的一致性和搜索服务的可用性；索引构建采用主磁盘索引+内存索引+从磁盘索引相结合的模型，保证最新的数据即时展现，实现搜索的实时性，实时索引的请求先 写CommitLog日志，保证实时索引的数据容灾性；搜索请求分为查询，更新，添加，删除4种，分别定位到分布式集群的一组或者多组服务器。

该搜索引擎分布式实现方法，采用分布式m×n的部署模型切分海量数据建立索引，实现高并发搜索请求量的随机软负载均衡，提升搜索系统性能。在索引量和搜索请求增加的情况下，动态添加行列的机器数量保证存储负载和搜索性能。其中，n列指系统划分为搜索服务器集群的个数，m行指单个搜索服务器集群包含搜索服务器的台数，m≥1且n≥1。

所述分布式m×n系统模型构建过程如下：

(1)自定义切分规则

根据系统需求，设定自定义的索引切分规则进行GroupFilter分组路由，例如分组规则用生成的索引Docment文档的Field域userId取模进行分组。分组规则不仅可以是单维，也可以是多维，即在m×n二维分组的基础上进行扩展，多维数组与一维数组存储机制一致，如先按userId取模分组后，再以用户所在的省份进行分组。

(2)确定m×n行列值

m和n的行列值取决于搜索服务器单机负载能力和分布式系统索引总量和搜索请求总量两个因素.

·搜索服务器单机负载能力。单机的索引数据容量由磁盘容量决定。建立新索引的过程中涉及索引的合并，旧的索引继续提供索引服务，此时的磁盘空间为：一份新索引+一份正提供服务的索引+索引合并所需磁盘空间，磁盘容量至少为索引数据的3倍。单机能承受的搜索请求量通过压力测试获取。当机器负载(load)值等于搜索服务器的CPU核数时，服务器所能承受的TPS(每秒请求数)为压力测试的峰值，如对于4核的服务器，通常在load＝4时的TPS为其单机所能承受的最高值。

·分布式系统索引总量和搜索请求总量。

所述分布式m×n系统模型中，m、n的计算式为：

n＝S/T；m＝Q/R+X；

其中S为索引总量，T为单机承载索引量，Q为搜索请求总量，R为单机承载搜索请求量，X为机器增量。

(3)建立分布式集群

根据索引切分规则和m、n的行列数，建立分布式搜索服务器集群；所有搜索服务器均提供搜索服务，搜索请求随机发送到组内的任一服务器；在同一组搜索服务器集群中，每一台搜索服务器分别向组内其他服务器发布感知服务，确保两两感知；

单组服务器集群内部，设定一台主服务器，其他均为从服务器，主服务器负责主索引的建立和写CommitLog日志文件，从服务器从主服务器中同步主索引，同步CommitLog日志建立内存索引；通过Master/Slave模型保证单组的索引数据容灾性，在组内某一搜索服务器宕机的情况下保证搜索服务的可用性。

所述索引数据包括主磁盘索引，内存索引，从磁盘索引3个部分；磁盘+内存的索引结构保证新增索引即时展现。写内存索引前先写CommitLog日志，持久化索引数据，保证内存索引数据不丢失；内存索引到达阈值后刷入从磁盘索引，保证可用性；索引数据的构建采用全量dump(转储)+实时增量dump的模型构建，全量dump采用时间周期任务定期执行，实时增量dump由实时调用接口生成。

所述索引数据构建过程如下：

(1)主磁盘索引构建

(a)搜索服务器定时触发全量dump程序：系统从数据源获取索引数据，数据源可以是网络爬虫抓取的信息、各种存储系统(数据库、文件、nosql系统等)；索引建立采用迭代器模型，利用DataProvider接口，首先利用hasNext()判断下一条语句是否存在，存在则用next()方法取下一条数据，构建并返回一条Map记录，直至hasNext()方法返回为false，结束整个迭代过程；Map记录对应一篇索引文档，Map的<key,value>键值对对应于文档的域和域值；利用封装好的Map对象构建Solr的AddUpdateCommand对象，最后调用Solr的UpdateHandle.addDoc()方法添加文档至索引；

(b)时间点设置：主索引构建过程开始时，记录一个时间点checkPoint；主索引建立完成后，提供搜索的服务将从旧索引替换到新索引，但是新索引建立过程中，会有增量的实时索引产生，因此需要补全在全量执行期间的增量数据，通过时间点机制从后补全实时索引；

(c)Slave服务器构建主索引：Master服务的主索引构建完成后，通知Slave服务器进行主索引的拷贝，并将checkPoint传递给Slave服务器，Slave服务器完成索引的构建工作后通知Master服务器，新的索引向外提供搜索服务；

(2)实时索引构建

(a)实时更新请求：实时请求可以与主索引同样来自于数据源，也可以来自客户端的实时接口调用；请求对象添加到CommitLog日志文件中；以实时接口调用为例，客户端调用Real-timeBean类的实时方法发送请求。实时请求方法分为Add(添加)、Update(更新)、Delete(删除)、mAdd(批量添加)、mUpdate(批量更新)、mDelete(批量删除)。服务器端接收实时请求，将实时请求封装为Document。

(b)CommitLog日志建立：所有的实时请求都写入主服务器的CommitLog日志中，持久化索引请求；搜索服务器启动时创建实时索引的构建进程Real-timeJob，不断轮循CommitLog日志，一旦有新的记录产生即进行写索引操作，根据请求类型的不同，分别调用Solr的UpdateHandler的相应方法建立内存索引；

(c)从磁盘索引建立：内存索引受限于内存大小，所以需要设定阈值，防止内存索引过大撑爆内存或者影响其他应用。当内存索引达到阈值时，新开一个内存索引，新来的实时请求写入新的内存索引，同时将旧的内存索引刷新至磁盘；利用内存索引与磁盘索引结构完全相同的特性，调用Directory的copy方法直接将内存索引拷贝至磁盘，形成从磁盘索引，提升搜索性能，实现立即搜索。

所述搜索功能实现包括查询、新增、更新、删除4种功能，查询功能操作不会修改索引数据结构，其他3种功能操作都会造成索引数据的修改，且有相应的批量操作方法。

所述搜索功能实现过程如下：

(1)搜索功能实现

用户发出搜索请求后，通过路由规则获取索引所在分布式搜索服务器组的集合；如果是单组搜索，需要对当前所有的索引进行搜索，包含主磁盘索引、内存索引、从磁盘索引，搜索结果过滤掉已被删除的文档；被删除文档的docId存储在delList集合中；多组搜索则利用Solr的shard概念对多组的结果集作合并操作；Solr服务是通过HTTP的方式提供服务，索引合并也都是通过HTTP方式发出请求进行合并，本系统对此作了改进。任意选定分组集中的一组，通过TCP/IP协议进行访问，此时利用Solr提供的EmbeddedSolrServer 获取当前组索引，并向其他组发送TCP/IP请求，获取索引数据并进行索引的merge操作，提高索引获取速度；

(2)添加、删除、更新功能实现

(a)添加功能实现：客户端发出Add命令，将其封装成添加请求写入CommitLog日志文件中；IndexBuildJob构建索引时进行判断，如为AddDocumentRequest请求，提取索引数据信息转换为Solr的AddUpdateCommand对象，最后调用Solr的UpdateHandle的AddDoc()命令，实现索引数据的添加。

(b)删除功能实现：客户端发出Delete命令，将其封装成删除请求DeleteDocumentRequest写入CommitLog日志文件中；在Lucene搜索引擎中有IndexWriter和IndexReader两个对象可以做删除动作，区别在于IndexWriter实例中删除的内容被缓存起来，并不会马上生效。搜索引擎接收实时删除请求后，如果待删除的文档在内存中，则用IndexWriter直接进行删除，否则在磁盘索引(即主索引和从索引)做标志删除，将文档保存至待删除的集合delList中。在内存索引提交时，调用IndexWriter的commit()方法，再调用磁盘索引的IndexReader方法逐个删除delList集合的元素。

(c)更新功能实现：与Add命令相同，客户端发出Update命令会被封装为UpdateDocumentRequest请求，写入CommitLog日志中。IndexBuildJob构建索引时，将索引数据信息转换为AddUpdateCommand，同时设置AllowDups为false，即不允许索引数据重复。此时Solr会首先判断索引是否已存在，有则删除，然后进行添加操作，完成更新。

为了验证该搜索引擎分布式实现方法，在大数据量高并发分布式环境下的实时性和数据容灾问题，进行了对比实验。实验由10台搜索服务器组成，分为5组，每组一主服务器一从服务器。

搜索服务器配置为：Intel○RXeo○R4核CPUE5520@2.27GHz、内存4GB、60GB硬盘7200转。索引总量为60GB、单机12GB，实验数据取平均值。

该搜索引擎分布式实现方法工程实现的原型系统为Xsolr，对比系统为Solr，数据集为4000万个文档，每个文档由22个域构成，平均大小为0.03KB，测试工具为LoadRunner。

实验结果分两部分，第一组实验为Xsolr与Solr系统的性能指标对比，结果见表1；

第二组实验为Xsolr的数据一致性与容灾。

表1 Xsolr与Solr实验结果对比

·实时响应性能。由表1可以看出，Xsolr的TPS和响应时间在4种测试条件下的性能均好于Solr。实时更新的请求响应时间均在1s以内。因为Xsolr更新操作在内存进行，索引在内存进行建立，而且不与磁盘索引进行合并，同时搜索内存和磁盘索引，减少磁盘I/O，加速了实时索引数据展示的速度。

·负载分析。在系统负载接近的情况下，Xsolr的CPU更加消耗资源。因为Xsolr会建立内存索引，实验环境下占用大量内存，最高时达到1GB。CPU使用率最高在30％左右，此时索引的更新TPS高达2100，大量占用内存，但是机器负载仍小于4，在可接受的范围内。

·数据一致性。前15s内，单机分别进行插入、更新、删除操作，主服务器与从服务器数据保持一致，有极细微区别。实时操作时，Slave不间断地从Master机器中拉取增量CommitLog日志文件，进行消费创建实时索引，保证主服务器与从服务器数据的一致性。但是由于CommitLog是顺序写入，且从Master机器拷贝文件有一定的网络开销，所以会出、现极细微的区别，在毫秒级别实现最终一致性，对系统整体服务影响极小，在可接受的范围内。

·数据容灾及完整性。17s时，Master服务器随机插入1000条记录，此时内存索引未达到阈值，不刷入从磁盘索引。30s时，Slave服务器恢复服务，其索引记录数与Master相同。35s后Master服务器宕机，60s后恢复启动，其索引记录数与Slave相同，且符合最初插入的1000条记录数。Xsolr通过CommitLog日志持久化实时数据，设置宕机恢复点。

Claims (8)

1.一种搜索引擎分布式实现方法，其特征在于：由分布式m×n系统模型构建，索引数据构建和搜索功能实现3部分组成；分布式集群组采用m×n模型，每一组集群内采用Master/Slave模型保证单组数据的一致性和搜索服务的可用性；索引构建采用主磁盘索引+内存索引+从磁盘索引相结合的模型，保证最新的数据即时展现，实现搜索的实时性，实时索引的请求先写CommitLog日志，保证实时索引的数据容灾性；搜索请求分为查询，更新，添加，删除4种，分别定位到分布式集群的一组或者多组服务器。

2.根据权利要求1所述的搜索引擎分布式实现方法，其特征在于：在索引量和搜索请求增加的情况下，所述分布式m×n系统模型动态添加行列的机器数量保证存储负载和搜索性能；其中，n列指系统划分为搜索服务器集群的个数，m行指单个搜索服务器集群包含搜索服务器的台数，m≥1且n≥1。

3.根据权利要求1或2所述的搜索引擎分布式实现方法，其特征在于，所述分布式m×n系统模型构建过程如下：

(1)自定义切分规则

根据系统需求，设定自定义的索引切分规则进行GroupFilter分组路由，分组规则既可以是单维也可以是多维，即在m×n二维分组的基础上进行扩展，多维数组与一维数组存储机制一致；

(2)确定m×n行列值

m和n的行列值取决于搜索服务器单机负载能力和分布式系统索引总量和搜索请求总量两个因素；

(3)建立分布式集群

根据索引切分规则和m、n的行列数，建立分布式搜索服务器集群；所有搜索服务器均提供搜索服务，搜索请求随机发送到组内的任一服务器；在同一组搜索服务器集群中，每一台搜索服务器分别向组内其他服务器发布感知服务，确保两两感知；

单组服务器集群内部，设定一台主服务器，其他均为从服务器，主服务器负责主索引的建立和写CommitLog日志文件，从服务器从主服务器中同步主索引，同步CommitLog日志建立内存索引；通过Master/Slave模型保证单组的索引数据容灾性，在组内某一搜索服务器宕机的情况下保证搜索服务的可用性。

4.根据权利要求3所述的搜索引擎分布式实现方法，其特征在于：所述分布式m×n系统模型中，m、n的计算式为：n＝S/T；m＝Q/R+X；其中S为索引总量，T为单机承载索引量，Q为搜索请求总量，R为单机承载搜索请求量，X为机器增量。

5.根据权利要求1所述的搜索引擎分布式实现方法，其特征在于：所述索引数据包括主磁盘索引，内存索引，从磁盘索引3个部分；写内存索引前先写CommitLog日志，持久化索引数据，保证内存索引数据不丢失；内存索引到达阈值后刷入从磁盘索引，保证可用性；索引数据的构建采用全量dump+实时增量dump的模型构建，全量dump采用时间周期任务定期执行，实时增量dump由实时调用接口生成。

6.根据权利要求1或5所述的搜索引擎分布式实现方法，其特征在于，所述索引数据构建过程如下：

(1)主磁盘索引构建

(a)搜索服务器定时触发全量dump程序：系统从数据源获取索引数据；索引建立采用迭代器模型，利用DataProvider接口，首先利用hasNext()判断下一条语句是否存在，存在则用next()方法取下一条数据，构建并返回一条Map记录，直至hasNext()方法返回为false，结束整个迭代过程；Map记录对应一篇索引文档，Map的<key,value>键值对对应于文档的域和域值；利用封装好的Map对象构建Solr的AddUpdateCommand对象，最后调用Solr的UpdateHandle.addDoc()方法添加文档至索引；

(b)时间点设置：主索引构建过程开始时，记录一个时间点checkPoint；主索引建立完成后，提供搜索的服务将从旧索引替换到新索引，但是新索引建立过程中，会有增量的实时索引产生，因此需要补全在全量执行期间的增量数据，通过时间点机制从后补全实时索引；

(c)Slave服务器构建主索引：Master服务的主索引构建完成后，通知Slave服务器进行主索引的拷贝，并将checkPoint传递给Slave服务器，Slave服务器完成索引的构建工作后通知Master服务器，新的索引向外提供搜索服务；

(2)实时索引构建

(a)实时更新请求：实时请求可以与主索引同样来自于数据源，也可以来自客户端的实时接口调用；请求对象添加到CommitLog日志文件中；

(b)CommitLog日志建立：所有的实时请求都写入主服务器的CommitLog日志中，持久化索引请求；搜索服务器启动时创建实时索引的构建进程Real-timeJob，不断轮循CommitLog日志，一旦有新的记录产生即进行写索引操作，根据请求类型的不同，分别调用Solr的UpdateHandler的相应方法建立内存索引；

(c)从磁盘索引建立：当内存索引达到阈值时，新开一个内存索引，新来的实时请求写入新的内存索引，同时将旧的内存索引刷新至磁盘；利用内存索引与磁盘索引结构完全相同的特性，调用Directory的copy方法直接将内存索引拷贝至磁盘，形成从磁盘索引，提升搜索性能，实现立即搜索。

7.根据权利要求1所述的搜索引擎分布式实现方法，其特征在于：所述搜索功能实现包括查询、新增、更新、删除4种功能，查询功能操作不会修改索引数据结构，其他3种功能操作都会造成索引数据的修改，且有相应的批量操作方法。

8.根据权利要求1或7所述的搜索引擎分布式实现方法，其特征在于，所述搜索功能实现过程如下：

(1)搜索功能实现

用户发出搜索请求后，通过路由规则获取索引所在分布式搜索服务器组的集合；如果是单组搜索，需要对当前所有的索引进行搜索，包含主磁盘索引、内存索引、从磁盘索引，搜索结果过滤掉已被删除的文档；被删除文档的docId存储在delList集合中；多组搜索则利用Solr的shard概念对多组的结果集作合并操作；任意选定分组集中的一组，通过TCP/IP协议进行访问，此时利用Solr提供的EmbeddedSolrServer获取当前组索引，并向其他组发送TCP/IP请求，获取索引数据并进行索引的merge操作，提高索引获取速度；

(2)添加、删除、更新功能实现

(a)添加功能实现：客户端发出Add命令，将其封装成添加请求写入CommitLog日志文件中；

(b)删除功能实现：客户端发出Delete命令，将其封装成删除请求DeleteDocumentRequest写入CommitLog日志文件中；

(c)更新功能实现：与Add命令相同，客户端发出Update命令会被封装为UpdateDocumentRequest请求，写入CommitLog日志中。