CN101196928A - 一种内容搜索方法、系统以及引擎分发单元 - Google Patents

Abstract

本发明公开了一种内容搜索方法，预先设置与至少一个处理器以及至少两个搜索引擎相连的引擎分发单元，该方法包括：引擎分发单元获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索。本发明还公开了一种内容搜索系统以及引擎分发单元。本发明的方案能够有效地提高内容搜索性能。

Description

一种内容搜索方法、系统以及引擎分发单元

技术领域

本发明涉及搜索技术，尤其涉及一种内容搜索方法、系统以及引擎分发单元。

背景技术

目前内容搜索已越来越广泛地应用于网络安全、信息查找等领域中，特别是对于作为当前热点之一的网络层和应用层技术，内容搜索效率就是一个较为关键的性能衡量。

图1示出了现有内容搜索系统的结构示意图。参见图1，该内容搜索系统中包括：处理器、缓存和搜索引擎，一个处理器和对应的缓存组成一个处理单元。在执行内容搜索时，处理器将诸如互联网协议(Internet Protocol，IP)报文之类的被搜索对象保存在缓存中，并通知搜索引擎启动搜索；搜索引擎在处理器的通知下启动直接存储器存取(Direct Memory Access，DMA)，通过与处理器之间的通道，将被搜索对象从缓存中读取到该搜索引擎内部，并根据预先设置的匹配规则，对被搜索对象执行基于字符(AC)或者基于正则表达式方式的匹配，并将表示是否搜索到与匹配规则相符的搜索结果存储到缓存中；处理器从缓存中读取搜索结果，完成内容搜索。

现有的内容搜索系统中处理单元以及搜索引擎是一对一的关系，具有固定搜索能力的搜索引擎采用串行方式执行内容搜索。当处理单元中的处理器将多个被搜索对象保存在缓存中时，该处理器对应的搜索引擎从缓存中位置在前的被搜索对象开始执行搜索，而位置在后的被搜索对象需要等待一定的排队时间才能够被执行搜索。可见，当存在多个搜索任务时，现有的内容搜索速度较低，搜索性能较差。

此外，在内容搜索过程中，匹配规则不同会导致搜索深度不同。例如：一种匹配规则是：在IP报文中搜索字符a，并且只要找到一个字符a搜索成功的搜索结果；另一种匹配规则是：搜索在IP报文中包括的字符a的数量。显而易见，第一种匹配规则对应的搜索深度较小，其搜索复杂度较低，因此搜索操作所需的时间也较少。然而，当位置在前的被搜索对象对应的匹配规则较为复杂时，即使位置在后的被搜索对象对应的匹配规则较为简单，后者也必须等待前者的搜索过程执行完毕，那么搜索速度就会十分缓慢，导致搜索性能较差。

再有，由于现有内容搜索系统中的每个处理器均对应于一个搜索引擎，各搜索引擎的搜索操作相互独立。当一个搜索引擎的未处理搜索任务很多时，其他搜索引擎即使处于空闲状态，也无法分担处于忙状态的搜索引擎的负荷，可见搜索任务的分布十分不均匀。这样一方面会导致搜索速度较慢，另一方面还会造成资源浪费的情况。

发明内容

本发明提供一种内容搜索方法，能够提高内容搜索性能。

在本发明的内容搜索方法中，包括：

引擎分发单元获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索。

本发明还提供一种内容搜索系统，能够提高内容搜索性能。

在本发明的内容搜索系统中，包括：至少一个处理器、引擎分发单元以及至少两个搜索引擎。其中，处理器用于发送被搜索对象；引擎分发单元用于获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；搜索引擎用于接收来自于引擎分发单元的被搜索对象，根据预先设置的匹配规则对该被搜索对象执行内容搜索。

本发明又提供一种引擎分发单元，能够提高内容搜索性能。

在本发明的引擎分发单元中，包括：前端处理模块和后端处理模块，其中前端处理模块用于获取来自于处理器的被搜索对象，将该被搜索对象发送出去；后端处理模块用于根据各搜索引擎的负荷确定执行内容搜索的搜索引擎，并将被搜索对象发送给所确定的被搜索引擎。

由上述方案可见，本发明中的引擎分发单元与至少一个处理器以及至少两个搜索引擎相连，并且在内容搜索过程中以搜索引擎的负荷作为标准来确定执行搜索操作的搜索引擎。当存在多个被搜索对象时，引擎分发单元可以将这些被搜索对象分配给若干个搜索引擎来执行内容搜索，从而减少被搜索对象的排队时间，有效地提高内容搜索速度，改善搜索性能。

并且，本发明中以搜索引擎的负荷作为分配标准，则可以将搜索复杂度较高的被搜索对象分配给负荷较小的搜索引擎，减少因在先被搜索对象的搜索复杂度较高而导致在后的被搜索对象长时间等待的情况，从而进一步提高搜索速度，改善搜索性能。

另一方面，本发明中全部的搜索引擎均由引擎分发单元来统一控制调度，这样可以实现多个搜索单元共享全部的搜索引擎。引擎分发单元可以将来自于同一个处理器的多个被搜索对象分散到不同的搜索引擎上，避免现有技术中一个搜索引擎十分繁忙、而其他搜索引擎比较空闲的情况，从而能够有效地平衡各搜索引擎之间的负荷，提高搜索速度的同时，减少资源浪费，提高系统中的设备利用率。

附图说明

图1为现有内容搜索系统的结构示意图。

图2为本发明中内容搜索方法的示例性流程图。

图3为本发明中内容搜索系统的示例性结构图。

图4为本发明实施例1中内容搜索系统的结构示意图。

图5为本发明实施例1中内容搜索系统初始化的方法流程图。

图6为本发明实施例1中内容搜索的方法流程图。

图7为本发明实施例2中内容搜索系统的结构示意图。

图8为本发明实施例3中内容搜索系统的结构示意图。

图9为本发明实施例4中内容搜索的方法流程图。

具体实施方式

为使本发明的目的、技术方案更加清楚明白，以下参照附图并举实施例，对本发明做进一步的详细说明。

本发明预先设置引擎分发单元，连接至少一个处理器和至少两个搜索引擎。这样，引擎分发单元就可以在处理器和搜索引擎之间起到控制调度作用。

图2示出了本发明中内容搜索方法的示例性流程图。参见图2，本发明按照如下步骤执行内容搜索：

在步骤201中，引擎分发单元获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；

在步骤202中，所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索。

图3示出了本发明中内容搜索系统的示例性结构图。参见图3，该系统包括：至少一个处理器、引擎分发单元以及至少两个搜索引擎。其中，处理器用于将被搜索对象发送给引擎分发单元；引擎分发单元用于获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；搜索引擎用于接收来自于引擎分发单元的被搜索对象，根据预先设置的匹配规则对该被搜索对象执行内容搜索。

从上述描述可见，本发明中的引擎分发单元与至少一个处理器以及至少两个搜索引擎相连，并且在内容搜索过程中以搜索引擎的负荷作为标准来确定执行搜索操作的搜索引擎。当存在多个被搜索对象时，引擎分发单元可以将这些被搜索对象分配给若干个搜索引擎来执行内容搜索，从而减少被搜索对象的排队时间，有效地提高内容搜索速度，改善搜索性能。并且，本发明中以搜索引擎的负荷作为分配标准，则可以将搜索复杂度较高的被搜索对象分配给负荷较小的搜索引擎，减少因在先被搜索对象的搜索复杂度较高而导致在后的被搜索对象长时间等待的情况，从而进一步提高搜索速度，改善搜索性能。

另一方面，本发明中全部的搜索引擎均由引擎分发单元来统一控制调度，这样可以实现多个搜索单元共享全部的搜索引擎。引擎分发单元可以将来自于同一个处理器的多个被搜索对象分散到不同的搜索引擎上，避免现有技术中一个搜索引擎十分繁忙、而其他搜索引擎比较空闲的情况，从而能够有效地平衡各搜索引擎之间的负荷，提高搜索速度的同时，减少资源浪费，提高系统中的设备利用率。

本发明中的引擎分发单元包括前端处理模块和后端处理模块，其中的前端处理模块用于获取来自于处理器的被搜索对象，将该被搜索对象发送给后端处理模块；后端处理模块用于根据各搜索引擎的负荷确定执行内容搜索的搜索引擎，并将被搜索对象发送给所确定的被搜索引擎。

此外，本发明可以在引擎分发单元中包括用于对被搜索对象进行缓存的第一缓存，或者在内容搜索系统中包括与处理器直接相连的第二缓存，或者，或者上述两种缓存均存在。在实际应用中，第一缓存和第二缓存均可以由先入先出(First In First Out，FIFO)存储器来实现。并且，本发明中的被搜索对象可以是网络层或者应用层中的报文，例如：IP报文。

下面以IP报文为例，详细说明本发明中的内容搜索方案。

实施例1

本实施例中处理器与引擎分发单元之间的接口以及搜索引擎与引擎分发单元之间的接口均可以是诸如高速周边元件扩展(Peripheral ComponentInterconnect express，PCIe)接口、串行外设接口4.0(Serial Peripheral Interface4.0，SPI4)或者超传输总线(Hyper Transport Bus，HT)之类的高速接口。并且挂接在引擎分发单元下的搜索引擎的数目由系统的吞吐量决定。

若引擎分发单元连接有两个或者两个以上的处理器，那么该内容搜索系统在投入使用之前，预先在各处理器与引擎分发单元之间的接口中确定管理接口，以便引擎分发单元和处理器之间传输配置信息和控制信息。本实施例可以采用下述两种方式确定管理接口：

1.默认方式：可以默认某个接口为管理接口，例如编号为0的接口；也可以预先设置各处理器与引擎分发单元之间的各接口作为管理接口的优先级，选择工作正常且优先级最高的接口作为管理接口。

2.选举方式：在系统启动时，各处理器在完成启动后，与引擎分发单元进行握手，最先握手成功的处理器对应的接口被确定为管理接口。当管理接口工作异常时，可以触发再次握手，将最先握手成功的处理器对应的接口确定为管理接口。这种方式下，可以为每个接口设置管理标志位，被选择为管理接口的接口对应的管理标志位被置1，其余接口对应的管理标志位被置0。

在确定了管理接口后，该接口对应的处理器被确定为管理单元，该管理单元可以通过管理接口获得引擎分发单元的工作状态等信息。

图4示出了本实施例中内容搜索系统的结构示意图。参见图4，该系统对图3中的引擎分发单元进行了细化，即本实施例中的引擎分发单元包括：前端处理模块、后端处理模块和第一缓存，这两个模块分别与处理器和搜索引擎直接通信。

为了保证本实施例中的内容搜索系统能够正常工作，在执行内容搜索之前，需要在该系统内执行初始化操作。图5示出了本实施例中内容搜索系统初始化的方法流程图。参见图5，该初始化流程包括：

在步骤501中，引擎分发单元获取当前与自身连接的搜索引擎的状态信息。

本步骤中，引擎分发单元中的后端处理模块通过扫描与搜索引擎之间的接口来确定当前与该引擎分发单元连接的各搜索引擎的当前状态，例如：是否能够正常工作等，并且引擎分发单元还同时确定出与自身连接并且工作正常的搜索引擎的数目；当然这里的状态信息还可以包括各搜索引擎的负荷信息。

在步骤502中，引擎分发单元通过管理接口将搜索引擎状态信息上报给管理单元。

在步骤503中，管理单元通过管理接口将缓存分配策略下发给引擎分发单元，引擎分发单元根据接收到的分配策略，为各处理器分配对应的第一缓存。

本步骤中的分配策略包括静态分配和动态分配两种类型。其中静态分配策略包括平均分配方式和根据处理能力分配方式；动态分配策略包括根据处理器负荷分配方式、根据缓存负荷分配方式以及根据处理器业务类型分配方式。若采用静态分配策略，可以只需在系统上电初期执行一次第一缓存的分配；若采用动态分配策略，则可以在系统上电初期执行一次第一缓存的分配，并且在系统运行过程中每当满足第一缓存调整条件时，都执行第一缓存的分配。

在静态策略的平均分配方式下，引擎分发单元的前端处理模块确定当前与自身连接的处理器数量，再将第一缓存的总容量除以所确定的处理器数量，得到每个处理器对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。

在静态策略的根据处理能力分配方式下，引擎分发单元的前端处理模块获取各处理器的处理能力，再根据获取到的处理能力为各处理器分配对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。具体来说，为处理能力较强的处理器分配较大容量的第一缓存，例如：处理器1的主频为500MHz，处理器2的主频为1GHz，那么为处理器1分配的第一缓存大小可以是处理器2的第一缓存大小的一半。

在动态策略的根据处理器负荷分配方式下，引擎分发单元的前端处理模块获取各处理器的负荷，为各处理器分配对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。具体来说，在系统运行之前，引擎分发单元的前端处理模块根据获取到的各处理器的负荷，为各处理器分配初始第一缓存容量，为负荷较重(处理器占有率较高)的处理器分配较小的初始第一缓存容量，并确定开始地址和结束地址；在系统运行过程中，引擎分发单元的前端处理模块继续获取各处理器的负荷，当获取到的处理器的负荷达到预先设置的处理器负荷上限时，降低该处理器对应的第一缓存容量；在获取到的处理器的负荷小于预先设置的处理器负荷下限时，增加该处理器对应的第一缓存容量。例如，当处理器占有率达到90％时，将该处理器的第一缓存容量降低至初始容量的一半；当处理器的占有率低于70％时，将该处理器的第一缓存容量恢复到初始容量。这里获取各处理单元负荷的方式可以有多种，例如各处理单元定期测量自身的负荷，并将测量到的负荷下发给引擎分发单元的前端处理模块；或者，引擎分发单元的前端处理模块通知各处理单元测量负荷，各处理单元再将测量到的负荷下发给引擎分发单元的前端处理模块。

在动态策略的根据缓存负荷分配方式下，系统运行之前，引擎分发单元的前端处理模块可以采用静态策略中的平均分配方式或者根据处理能力分配方式，为各处理器分配初始第一缓存容量以及开始地址和结束地址，并通知给对应的处理器；在系统运行时，检测各处理器的缓存负荷，当处理器的缓存负荷超过预先设置的缓存负荷上限已持续预先设置的时间长度时，增加该处理器对应的第一缓存容量；当处理器的缓存负荷低于预先设置的缓存负荷下限已持续预先设置的时间长度时，降低该处理器的第一缓存容量。例如，当处理器的第一缓存处于满负荷状态的时间超过10分钟，则将该处理器的第一缓存容量增加到等于初始容量的150％；当处理器的第一缓存处于低于50％负荷状态已10分钟，则将该处理器的第一缓存容量减半。

在动态策略的根据处理器业务类型分配方式下，引擎分发单元的前端处理模块获取各处理器当前承载的业务类型，为各处理器分配对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。具体来说，引擎分发单元的前端处理模块可以通过解析IP报文头或者报文内容来获得业务类型，当然，解析IP报文头的方式效率更高。

在完成第一缓存的分配之后，结束本实施例中的初始化流程。当然，若系统不包含缓存，则执行完上述的步骤501和502即可结束初始化。

图6示出了本实施例中内容搜索的方法流程图。参见图6，这里的内容搜索过程包括：

在步骤601中，处理器将作为被搜索对象的IP报文发送给引擎分发单元。

本步骤中，当处理器确定存在需要进行内容搜索的IP报文时，将该报文作为被搜索对象，通过与引擎分发单元之间的接口，下发给引擎分发单元中的前端处理模块。之后，前端处理模块将接收到的IP报文保存在该处理器对应的第一缓存中。后端处理模块可以采用两种方式从第一缓存中读取来自于处理器的IP报文。在第一种方式下，后端处理模块对第一缓存定期扫描，当发现第一缓存中存在IP报文时，就顺次进行报文的读取；在第二种方式下，每当前端处理模块将接收到的IP报文保存在第一缓存中，该前端处理模块都通知后端处理模块出现被搜索对象，后端处理模块接收到通知后，直接从第一缓存中读取作为被搜索对象的IP报文。在后一种方式下，前端处理模块可以在通知中同时携带被搜索对象的优先级，这样后端处理模块就可以按照优先级从高到低的顺序从第一缓存中依次读取被搜索对象。

在步骤602～604中，引擎分发单元将与自身连接的一个搜索引擎作为当前搜索引擎，检测当前搜索引擎的当前负荷，并判断检测到的当前负荷是否达到预先设置的搜索引擎负荷阈值，如果是，则执行步骤605；否则，执行步骤608。

这里引擎分发单元的后端处理模块可以按照搜索引擎的编号顺序，将第一个搜索引擎作为此处的当前搜索引擎；也可以在与引擎分发单元相连接且能够正常工作的搜索引擎中任选一个，作为当前搜索引擎。

本实施例中，每个搜索引擎内部均包括一个第三缓存，该第三缓存的容量以能够保存的数据包个数表示。那么引擎分发单元的后端处理模块可以检测发送给搜索引擎的IP报文数目、搜索引擎完成处理返回的IP报文数目以及搜索引擎的第三缓存容量，然后计算搜索引擎的当前负荷，即搜索引擎的当前负荷＝(发送给搜索引擎的IP报文数目-搜索引擎完成处理返回的IP报文数目)/搜索引擎的第三缓存容量，此时得到的当前负荷是以百分比形式表示的数值。

在步骤605～607中，判断是否在本次遍历中已检测过所有的搜索引擎，如果是，则发出搜索引擎满负荷的告警，并返回执行步骤602；否则，选择本次遍历中未被检测过负荷的一个搜索引擎，作为当前搜索引擎，并返回执行步骤603。

本实施例中，当所有的搜索引擎均被执行过一次负荷检测时，认为完成一次对所有搜索引擎的遍历。

若本次遍历中已经检测过所有的搜索引擎，即当前搜索引擎是本次遍历中的最后一个搜索引擎但是其负荷很大时，表明当前情况下挂接在引擎分发单元上的所有搜索引擎均无法再执行额外的内容搜索任务，那么引擎分发单元中的后端处理模块通过前端处理模块向步骤601中发送IP报文的处理器发出表示搜索引擎满负荷告警，指明目前所有的搜索引擎目前无法处理该IP报文的内容搜索。

若还存在本次遍历中未被检测负荷的搜索引擎，表示存在找到适合的搜索引擎的可能性，因此再选择一个搜索引擎，进行负荷检测。

在步骤608～610中，将引擎分发单元接收到的IP报文发送给当前搜索引擎，当前搜索引擎按照预先设置的匹配规则对该IP报文进行内容搜索，并将搜索结果返回给引擎分发单元，引擎分发单元将接收到的搜索结果返回给发出该IP报文的处理器。

这里可以按照现有方式对IP报文进行内容搜索。在搜索引擎完成内容搜索后，将得到的搜索结果返回给引擎分发单元中的后端处理模块，后端处理模块将接收到的搜索结果提交给前端处理模块，前端处理模块再转发给在步骤601中发出IP报文的处理器。

至此，结束本实施例中的内容搜索流程。

从上述描述可见，本实施例中的内容搜索方案除了能够有效地提高内容搜索速度、改善搜索性能、减少资源浪费之外，由于在现有系统基础上仅增加了引擎分发单元，因此实现较为简单，成本较低；并且，本实施例中初始化过程中可以采用多种方式为处理器分配第一缓存，能够满足与内容搜索相关联的多种存储需求，避免因第一缓存较小而被搜索对象较大导致的无法存储的情况，从而保证内容搜索的顺利进行。

相应地，对于图4示出的本实施例中的内容搜索系统，引擎分发单元中的前端处理模块接收来自处理器的被搜索对象，将接收到的被搜索对象保存在该处理器对应的第一缓存中；接收来自于后端处理模块的搜索结果，并将接收到的搜索结果返回给发出该被搜索对象的处理器。第一缓存用于保存前端处理模块发来的被搜索对象。后端处理模块用于从发出被搜索对象的处理器对应的第一缓存中读取该被搜索对象，根据搜索引擎的负荷确定执行内容搜索的搜索引擎，即将负荷低于预先设置的搜索引擎负荷阈值的一个搜索引擎选择为当前搜索引擎，并将读取到的被搜索对象发送给搜索引擎，接收来自于搜索引擎的搜索结果，将该搜索结果返回给前端处理模块。

并且，后端处理模块在从第一缓存中读取被搜索对象时，可以定期扫描所有处理器的第一缓存，当确定第一缓存中存在被搜索对象时，读取该被搜索对象；或者前端处理模块在将被搜索对象保存在处理器对应的第一缓存中之后，通知后端处理模块出现被搜索对象，后端处理模块根据接收到的通知从该处理器对应的第一缓存中读取被搜索对象；或者前端处理模块在发给后端处理模块的通知中携带被搜索对象的优先级，后端处理模块按照优先级从高到低的顺序从第一缓存中依次读取被搜索对象。

在初始化过程中，本实施例中引擎分发单元中的前端处理模块接收来自于作为管理单元的处理器的缓存分配策略，接收来自于后端处理模块的各搜索引擎的状态信息，根据缓存分配策略和各搜索引擎的状态信息，为各处理器分配对应的第一缓存，并将第一缓存容量以及开始地址和结束地址返回给对应的处理器。后端处理模块确定当前与该引擎分发单元连接的各搜索引擎的当前状态，将得到的状态信息发送给前端处理模块。

实施例2

本实施例与实施例1的区别在于，本实施例中的引擎分发单元中不包括第一缓存，但是在内容搜索系统中包括与各处理器直接相连的第二缓存。图7示出了本实施例中内容搜索系统的结构示意图。参见图7，该系统包括：处理器、第二缓存、引擎分发单元以及搜索引擎。处理器的操作与实施例1相似，只是采用间接的方式来发送被搜索对象，即将被搜索对象发送给第二缓存，再由引擎分发单元通过处理器到第二缓存中获取被搜索对象。第二缓存用于保存来自于处理器的被搜索对象。引擎分发单元通过处理器从第二缓存中获取被搜索对象，而后按照与实施例1相同的方式确定执行搜索的搜索引擎，并返回搜索结果。搜索引擎与实施例1相同。

具体到引擎分发单元内部，前端处理模块通过处理器从第二缓存中获取被搜索对象，将获取到的被搜索对象发送给后端处理模块，接收来自于后端处理模块的搜索结果，将该搜索结果返回给对应的处理器。后端处理模块接收前端处理模块发送的被搜索对象，根据搜索引擎的负荷确定执行内容搜索的搜索引擎，即将负荷低于预先设置的搜索引擎负荷阈值的一个搜索引擎选择为当前搜索引擎，并将读取到的被搜索对象发送给搜索引擎，接收来自于搜索引擎的搜索结果，将该搜索结果返回给前端处理模块。

本实施例中的内容搜索系统在初始化时，由于第二缓存与处理器相连，因此各处理器可以分别对自身对应的第二缓存进行初始化，而无需执行分配第一缓存的操作。换言之，初始化时，引擎分发单元中的后端处理模块获取当前与该引擎分发单元连接的搜索引擎的状态信息，并提交给前端处理模块；前端处理模块将接收到的搜索引擎状态信息上报给作为管理单元的处理器。

对于内容搜索流程，本实施例在初始阶段传输作为被搜索对象的IP报文处与实施例1有所不同。具体来说，本实施例中处理器先将作为被搜索对象的IP报文保存在自身对应的第二缓存中，引擎分发单元再通过该处理器从该第二缓存中获取IP报文。这里的获取方式可以有多种，例如：引擎公发单元定期扫描各处理器对应的第二缓存，在确定第二缓存中存在被搜索对象时，通过处理器读取该被搜索对象；或者处理器在将被搜索对象保存在自身对应的第二缓存中后，通知引擎分发单元出现被搜索对象，引擎分发单元根据接收到的通知通过该处理器从对应的第二缓存中读取被搜索对象；或者，处理器在发给引擎分发单元的通知中携带被搜索对象的优先级，引擎分发单元按照优先级从高到低的顺序从该处理器对应的第二缓存中依次读取被搜索对象。

而后，可以按照实施例1中的步骤602至610进行内容搜索。

实施例3

本实施例将实施例1和实施例2相结合，即在本实施例的内容搜索系统中既包括第一缓存又包括第二缓存。

图8示出了本实施例中内容搜索系统的结构示意图。参见图8，该系统包括：处理器、第二缓存、引擎分发单元以及搜索引擎。引擎分发单元中包括前端处理模块、第一缓存以及后端处理模块。

本实施例中的初始化过程与实施例1中的初始化过程完全相同。

在内容搜索过程中，本实施例首先按照实施例2的方式，由处理器先将被搜索对象保存在自身对应的第二缓存中，引擎分发单元再从该第二缓存中获取IP报文。这里的获取方式可以与实施例2相同。然后，引擎分发单元中的前端处理模块按照实施例1的步骤601中所执行的操作，将接收到的IP报文保存在该处理器对应的第一缓存中，后端处理模块再从第一缓存中读取来自于处理器的IP报文。这里后端处理模块读取IP报文的操作与实施例1相同。此后，可以按照实施例1的步骤602至610执行内容搜索。

上述三个实施例中的搜索引擎既能够基于字符方式进行内容搜索，又能够基于正则表达式方式进行内容搜索。

实施例4

本实施例中可以根据匹配规则的类型对搜索引擎进行分类，例如，将搜索引擎分为字符型搜索引擎和正则表达式型搜索引擎，其中字符型搜索引擎只能够执行基于字符方式的内容搜索，由于这种方式的搜索任务较为简单，因此搜索速度较快；而正则表达式型搜索引擎既可以执行基于字符方式的内容搜索，又可以执行基于正则表达式方式的内容搜索。那么，本实施例中在确定执行搜索的搜索引擎时，可以先从字符型搜索引擎开始检测负荷，当所有字符型搜索引擎均无法对被搜索对象执行内容搜索时，再从正则表达式型搜索引擎中选择适合的搜索引擎。

图9示出了本实施例中内容搜索方法的流程图。参见图9，该方法包括：

在步骤901中，处理器将作为被搜索对象的IP报文发送给引擎分发单元。

本步骤中，可以像实施例1那样由处理器将IP报文发送给引擎分发单元中对应的第一缓存，引擎分发单元的后端处理模块再从第一缓存中读取该IP报文；也可以像实施例2那样由处理器将IP报文保存在与自身相连的第二缓存中，引擎分发单元的前端处理模块从第二缓存中读取该IP报文，再传输给后端处理模块；还可以像实施例3那样由处理器将IP报文保存在与自身相连的第二缓存中，引擎分发单元的前端处理模块从第二缓存中读取该IP报文，将读取到的IP报文保存在该处理器对应的第一缓存中，后端处理模块再从第一缓存中读取该IP报文。

在步骤902中，引擎分发单元将与自身连接的一个字符型搜索引擎作为当前搜索引擎。

由于本实施例中引擎分发单元在获得作为被搜索对象的IP报文后，无法确定应用何种类型的匹配规则对该IP报文执行搜索，而字符型搜索引擎执行内容搜索的效率较高、速度较快，因此从字符型搜索引擎开始，并通过后续步骤确定该字符型搜索引擎是否能够执行该IP报文的内容搜索。

在步骤903～904中，判断当前搜索引擎的当前负荷是否达到预先设置的搜索引擎负荷阈值，如果是，则执行步骤905；否则，执行步骤913。

在步骤905～907中，判断本次遍历中是否已检测所有字符型搜索引擎；如果是，则引擎分发单元将与自身连接的一个正则表达式型搜索引擎作为当前搜索引擎；否则，选择一个未检测负荷的字符型搜索引擎，并返回执行步骤903。

在当前搜索引擎的负荷达到搜索引擎负荷阈值时，表明当前搜索引擎无法再承担更多的内容搜索任务，则衡量下一个字符型搜索引擎的负荷；若此时所有的字符型搜索引擎均处于负荷较高的状态，则转向正则表达式型搜索引擎。

在步骤908～909中，检测当前搜索引擎的当前负荷，判断当前搜索引擎的当前负荷是否达到搜索引擎负荷阈值，如果是，则执行步骤910；否则，执行步骤913。

本步骤中衡量正则表达式型搜索引擎负荷的搜索引擎负荷阈值可以与衡量字符型搜索引擎的阈值相同或者不同。当两者不同时，为了便于区分，可以将步骤904中的阈值称为字符型搜索引擎阈值，将这里的阈值称为正则表达式型搜索引擎阈值。

若属于正则表达式型的当前搜索引擎的负荷足以承担对步骤901中IP报文的内容搜索任务，那么通过步骤913开始进行内容搜索。

在步骤910～911中，判断本次遍历中是否已检测所有正则表达式型搜索引擎，如果是，则发出搜索引擎满负荷告警，并返回执行步骤902；否则，执行步骤912。

在步骤912中，选择一个未检测负荷的正则表达式型搜索引擎作为当前搜索引擎，并返回执行步骤908。

若目前没有找到负荷适合的搜索引擎，但是仍然存在未被检测负荷的正则表达式型搜索引擎，则继续寻找能够承担内容搜索任务的搜索引擎。

上述的步骤902至步骤912均由引擎分发单元中的后端处理模块执行。

在步骤913～914中，将引擎分发单元接收到的IP报文发送给当前搜索引擎，当前搜索引擎按照预先设置的匹配规则对该IP报文执行内容搜索。

在通过负荷选择出能够承担内容搜索任务的字符型或者正则表达式型搜索引擎后，引擎分发单元的后端处理模块将作为被搜索对象的IP报文传送给被选择的当前搜索引擎。

在步骤915～916中，判断引擎分发单元是否接收到当前搜索引擎返回的结果，如果是，则引擎分发单元将搜索结果返回给发出该IP报文的处理器，并结束内容搜索流程；否则，返回执行步骤910。

由于字符型搜索引擎无法执行基于正则表达式的内容搜索，那么字符型搜索引擎接收到IP报文并且发现无法完成内容搜索时，不会返回任何搜索结果。此时，无需再选择其他的字符型搜索引擎，而是直接转向正则表达式型搜索引擎。此外，若当前搜索引擎属于正则表达式型，但是由于各种原因而未能返回搜索结果，那么转向另外的正则表达式型搜索引擎。

这里可以预先设置搜索结果等待时间阈值，当步骤913中将IP报文发送给当前搜索引擎时，开始计时。若计时时间超过搜索结果等待时间阈值还仍然未接收到当前搜索引擎返回的搜索结果，则认为未接收到搜索结果。

至此，结束本实施例中的内容搜索流程。

本实施例中按照匹配规则的类型预先将搜索引擎分为字符型搜索引擎和正则表达式型搜索引擎，在内容搜索过程中，首先从字符型搜索引擎开始寻找负荷合适的搜索引擎，在确定不存在负荷满足要求的字符型搜索引擎或者字符型搜索引擎无法完成内容搜索任务时，转向正则表达式型搜索引擎。这样，通过分类使得搜索引擎的选择范围有效地缩小，从而能够一定程度上节省选择搜索引擎的时间，从而提高内容搜索过程的执行效率。

本实施例可以采用图4、图7或者图8示出的内容搜索系统，并且该系统中除后端处理模块之外的其他部分均与实施例1、2和3相同。对于本实施例中的后端处理模块，接收被搜索对象，将与引擎分发单元连接的搜索引擎分为字符型和正则表达式型，从字符型搜索引擎开始，将负荷低于预先设置的搜索引擎负荷阈值的字符型搜索引擎或者正则表达式型搜索引擎选择为执行内容搜索的搜索引擎，将被搜索对象发送给所选择的搜索引擎，若接收到搜索结果，则将接收到的搜索结果返回给前端处理模块；若未接收到搜索结果，则再选择负荷低于搜索引擎负荷阈值的正则表达式型搜索引擎，返回执行将被搜索对象发送给所选择的搜索引擎的操作。

通过上述对实施例1至4的描述，本发明采用引擎分发单元来将至少一个处理器以及至少两个搜索引擎连接在一起，形成搜索引擎阵列，能够灵活地处理内容搜索任务，缩短内容搜索时间，提高效率；还能够通过引擎分发单元对多个搜索引擎进行统一调度，从而充分利用资源，避免搜索引擎负荷不均衡的情况出现；此外，本发明中可以灵活地对搜索引擎进行扩展和精简时，即只需将新的搜索引擎连接到引擎分发单元上或者将需要精简的搜索引擎从引擎分发单元上端口解除连接即可，操作简单，易于实现，并且良好的可扩展性还能够有效地提高内容搜索引擎的处理能力。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (30)

1.一种内容搜索方法，其特征在于，预先设置与至少一个处理器以及至少两个搜索引擎相连的引擎分发单元，该方法包括：

引擎分发单元获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；

所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索。

2.如权利要求1所述的方法，其特征在于，所述根据各搜索引擎的负荷确定执行搜索的搜索引擎为：

所述引擎分发单元将负荷小于预先设置的搜索引擎阈值的搜索引擎确定为所述执行搜索的搜索引擎。

3.如权利要求2所述的方法，其特征在于，所述引擎分发单元将负荷小于预先设置的搜索引擎阈值的搜索引擎确定为所述执行搜索的搜索引擎为：

引擎分发单元将与自身连接的一个搜索引擎作为当前搜索引擎，检测当前搜索引擎的当前负荷；

判断当前负荷是否达到所述搜索引擎负荷阈值，如果是，选择本次遍历中未被检测过负荷的一个搜索引擎，作为当前搜索引擎，并返回执行所述检测；否则，将当前搜索引擎确定为所述执行搜索的搜索引擎。

4.如权利要求3所述的方法，其特征在于，所述选择本次遍历中未被检测过负荷的一个搜索引擎之前，进一步包括：

判断是否在本次遍历中已检测过所有的搜索引擎，如果是，则返回执行所述引擎分发单元将与自身连接的一个搜索引擎作为当前搜索引擎；否则，执行所述选择本次遍历中未被检测过负荷的一个搜索引擎。

5.如权利要求2所述的方法，其特征在于，所述搜索引擎包括：字符型搜索引擎和正则表达式型搜索引擎；

所述引擎分发单元将负荷小于预先设置的搜索引擎阈值的搜索引擎确定为所述执行搜索的搜索引擎为：从字符型搜索引擎开始，将负荷低于预先设置的搜索引擎负荷阈值的字符型搜索引擎或者正则表达式型搜索引擎确定为所述执行搜索的搜索引擎。

6.如权利要求5所述的方法，其特征在于，从字符型搜索引擎开始，将负荷低于预先设置的搜索引擎负荷阈值的字符型搜索引擎或者正则表达式型搜索引擎确定为所述执行搜索的搜索引擎为：

B11.引擎分发单元将与自身连接的一个字符型搜索引擎作为当前搜索引擎，检测当前搜索引擎的当前负荷；

B12.判断当前搜索引擎的当前负荷是否达到预先设置的字符型搜索引擎负荷阈值，如果是，执行步骤B13；否则，将当前引擎分发单元确定为所述执行搜索的搜索引擎，并继续执行所述所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索；

B13.判断是否在本次遍历中已检测过所有的字符型搜索引擎，如果是，则引擎分发单元将与自身连接的一个正则表达式型搜索引擎作为当前搜索引擎，检测当前搜索引擎的当前负荷，并执行步骤B14；否则，选择本次遍历中未被检测过负荷的一个字符型搜索引擎，作为当前搜索引擎，并返回执行步骤B11中所述的检测；

B14.判断所述当前搜索引擎是否达到预先设置的正则表达式型搜索引擎负荷阈值，如果是，选择本次遍历中未被检测过负荷的一个正则表达式型搜索引擎，作为当前搜索引擎，并返回执行步骤B13中所述的检测；否则，将当前引擎分发单元确定为所述执行搜索的搜索引擎，并继续执行所述所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索。

7.如权利要求6所述的方法，其特征在于，步骤B14中所述选择本次遍历中未被检测过负荷的一个正则表达式型搜索引擎之前，进一步包括：

判断本次遍历中是否已检测所有正则表达式型搜索引擎，如果是，则返回执行步骤B11；否则，执行所述选择本次遍历中未被检测过负荷的一个正则表达式型搜索引擎。

8.如权利要求7所述的方法，其特征在于，所述所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索之后，进一步包括：

所述引擎分发单元在未接收到来自于所确定的搜索引擎返回的搜索结果时，执行所述判断本次遍历中是否已检测所有正则表达式型搜索引擎。

9.如权利要求1或8所述的方法，其特征在于，所述所确定的搜索引擎根据预先设置的匹配规则对该被搜索对象执行内容搜索之后，进一步包括：

所述搜索引擎分发单元在接收到来自于所确定的搜索引擎返回的搜索结果时，将接收到的搜索结果返回给发出所述被搜索对象的处理器。

10.如权利要求1至8中任意一项所述的方法，其特征在于，所述引擎分发单元获得来自于处理器的被搜索对象之前，进一步包括：

对所述处理器、引擎分发单元以及搜索引擎进行初始化。

11.如权利要求10所述的方法，其特征在于，所述初始化为：

引擎分发单元获取当前与自身连接的搜索引擎的状态信息，并通过预先确定的管理接口将搜索引擎状态信息上报给作为管理单元的处理器。

12.如权利要求11所述的方法，其特征在于，所述引擎分发单元中进一步包括：第一缓存；

所述上报给作为管理单元的处理器之后，进一步包括：所述引擎分发单元根据预先确定的缓存分配策略为各处理器分配对应的第一缓存。

13.如权利要求12所述的方法，其特征在于，所述引擎分发单元根据预先确定的缓存分配策略为各处理器分配对应的第一缓存为：

引擎分发单元确定当前与自身连接的处理器数量，将第一缓存的总容量除以所确定的处理器数量，得到每个处理器对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器；

或者，所述引擎分发单元获取各处理器的处理能力，再根据获取到的处理能力为各处理器分配对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。

14.如权利要求13所述的方法，其特征在于，所述通知给对应的处理器之后，进一步包括：

所述引擎分发单元检测各处理器的第一缓存负荷，当第一缓存负荷超过预先设置的缓存负荷上限已持续预先设置的时间长度时，增加该处理器对应的第一缓存容量；当处理器的缓存负荷低于预先设置的缓存负荷下限已持续预先设置的时间长度时，降低该处理器的第一缓存容量；

将增加或者降低的第一缓存容量通知给对应的处理器。

15.如权利要求12所述的方法，其特征在于，所述引擎分发单元根据预先确定的缓存分配策略为各处理器分配对应的第一缓存为：

所述引擎分发单元获取各处理器的负荷，根据获取到的负荷为各处理器分配对应的初始第一缓存容量，并确定给开始地址和结束地址，通知给对应的处理器；

引擎分发单元检测各处理器运行中的负荷，当负荷达到预先设置的处理器负荷上限时，降低该处理器对应的第一缓存容量，当负荷小于预先设置的处理器负荷下限时，增加该处理器对应的第一缓存容量，并将降低或者增加后的第一缓存容量通知给对应的处理器。

16.如权利要求12所述的方法，其特征在于，所述引擎分发单元根据预先确定的缓存分配策略为各处理器分配对应的第一缓存为：

所述引擎分发单元获取各处理器当前承载的业务类型，为各处理器分配对应的第一缓存容量以及开始地址和结束地址，并通知给对应的处理器。

17.一种引擎分发单元，其特征在于，该引擎分发单元包括：前端处理模块和后端处理模块，其中，

所述前端处理模块用于获取来自于处理器的被搜索对象，将该被搜索对象发送出去；

所述后端处理模块用于根据各搜索引擎的负荷确定执行搜索的搜索引擎，并将所述被搜索对象发送给对确定的被搜索引擎。

18.如权利要求17所述的引擎分发单元，其特征在于，该引擎分发单元进一步包括：第一缓存，用于保存来自前端处理模块的被搜索对象；

所述前端处理模块将所述被搜索对象发送给发出该被搜索对象的处理器对应的第一缓存，并通知所述后端处理模块出现被搜索对象，后端处理模块根据接收到的通知从所述第一缓存中读取所述被搜索对象；或者，所述前端处理模块将所述被搜索对象发送给发出该被搜索对象的处理器对应的第一缓存，所述后端处理模块通过定期扫描确定所述第一缓存中存在被搜索对象后，从所述第一缓存中读取所述被搜索对象。

19.如权利要求18所述的引擎分发单元，其特征在于，所述后端处理模块进一步用于根据预先确定的缓存分配策略为各处理器分配对应的第一缓存，并将各处理器的第一缓存容量以及开始地址和结束地址发送给前端处理模块；

所述前端处理模块进一步用于将接收到的第一缓存容量以及开始地址和结束地址发送给对应的处理器。

20.如权利要求17、18或19中任意一项所述的引擎分发单元，其特征在于，所述前端处理模块定期扫描所述处理器对应的第二缓存或者接收来自于所述处理器的通知，通过该处理器从对应的第二缓存中读取所述被搜索对象。

21.如权利要求17所述的引擎分发单元，其特征在于，所述后端处理模块进一步获取当前与所在引擎分发单元连接的搜索引擎的状态信息，发送给前端处理模块；

所述前端处理模块进一步用于通过预先设置的管理接口，将所述搜索引擎的状态信息上报给作为管理单元的处理器。

22.如权利要求17所述的引擎分发单元，其特征在于，所述后端处理模块将负荷小于预先设置的搜索引擎阈值的搜索引擎确定为所述执行搜索的搜索引擎。

23.如权利要求22所述的引擎分发单元，其特征在于，所述后端处理模块将与所在引擎分发单元连接的一个搜索引擎作为当前搜索引擎，检测当前搜索引擎的当前负荷；判断当前负荷是否达到所述搜索引擎负荷阈值，如果是，选择本次遍历中未被检测过负荷的一个搜索引擎，作为当前搜索引擎，并返回执行所述检测；否则，将当前搜索引擎确定为所述执行搜索的搜索引擎。

24.如权利要求22所述的引擎分发单元，其特征在于，所述后端处理模块从字符型搜索引擎开始，将负荷低于预先设置的搜索引擎负荷阈值的字符型搜索引擎或者正则表达式型搜索引擎确定为所述执行搜索的搜索引擎。

25.如权利要求17、22、23、24中任意一项所述的引擎分发单元，其特征在于，所述后端处理模块进一步将搜索引擎返回的搜索结果发送给前端处理模块；所述前端处理模块进一步将所述搜索结果返回给发出所述被处理对象的处理器。

26.一种内容搜索系统，其特征在于，该系统包括：至少一个处理器、引擎分发单元以及至少两个搜索引擎，其中，

所述处理器用于发送被搜索对象；

所述引擎分发单元用于获得来自于处理器的被搜索对象，根据各搜索引擎的负荷确定执行搜索的搜索引擎；

所述搜索引擎用于接收来自于引擎分发单元的被搜索对象，根据预先设置的匹配规则对该被搜索对象执行内容搜索。

27.如权利要求26所述的内容搜索系统，其特征在于，所述引擎分发单元包括：前端处理模块和后端处理模块，其中，

所述前端处理模块用于获取来自于处理器的被搜索对象，将该被搜索对象发送出去；

所述后端处理模块用于根据各搜索引擎的负荷确定执行搜索的搜索引擎，并将所述被搜索对象发送给对确定的被搜索引擎。

28.如权利要求27所述的内容搜索系统，其特征在于，所述引擎分发单元进一步包括：第一缓存，用于保存来自所述前端处理模块的被搜索对象；

所述前端处理模块将所述被搜索对象发送给发出该被搜索对象的处理器对应的第一缓存，并通知所述后端处理模块出现被搜索对象，后端处理模块根据接收到的通知从所述第一缓存中读取所述被搜索对象；或者，所述前端处理模块将所述被搜索对象发送给发出该被搜索对象的处理器对应的第一缓存，所述后端处理模块通过定期扫描确定所述第一缓存中存在被搜索对象后，从所述第一缓存中读取所述被搜索对象。

29.如权利要求26至28中任意一项所述的内容搜索系统，其特征在于，该系统进一步包括：第二缓存，用于保存来自于自身对应的处理器的被搜索对象；

所述处理器将被搜索对象发送给自身对应的第二缓存，并通知引擎分发单元出现被搜索对象，引擎分发单元根据接收到的通知，通过所述处理器从所述第二缓存中读取被搜索对象；或者，所述处理器将被搜索对象发送给自身对应的第二缓存，引擎分发单元通过定期扫描所述处理器对应的第二缓存确定存在被搜索对象后，通过所述处理器从该第二缓存中读取所述被搜索对象。

30.如权利要求26所述的内容搜索系统，其特征在于，所述搜索引擎进一步将对所述被搜索对象进行内容搜索得到的搜索结果返回给引擎分发单元；

所述引擎分发单元进一步将接收到的搜索结果返回给发出所述被搜索对象的处理器。

Images