一种基于特定策略降低搜索复杂度以应对超负荷搜索请求的方法

技术领域

本发明涉及数据搜索技术领域，特别是涉及一种基于特定策略降低搜索复杂度以应对超负荷搜索请求的方法；

背景技术

搜索系统是高负荷计算系统，需要占用大量的CPU计算时间和内存资源，同时线上的搜索系统又需要保持高可用性，并且响应时间要求在毫秒级，因此其占用的系统资源和其能处理的最大搜索请求并发一定是成一定范围比例的；

公司运营需要考虑经济效益，所花费的硬件成本是有限的；对于搜索平台来说，在整个业务系统中属于后台服务提供者，其开放给所有接入的业务系统使用，其承担的总处理能力是相对有限的；当出现超负荷搜索请求，即搜索请求并发数量超过系统最大负荷时，搜索平台会容易出现实例内存溢出或负载过高导致应用崩溃无法提供服务的情况；为了在有限的硬件成本下，可以应对这种超负荷搜索请求出现；需要搜索平台系统能够有一种基于某种特定策略来降低搜索复杂程度，通过有损服务的思想来实现应对超负荷请求；

有损服务思想是公认的基于有限资源下，通过牺牲部分不重要或者非核心的用户体验来最大程度满足基本服务需求；搜索平台提供的是一个搜索服务，本身即含有一定的模糊性，其天然区分于数据库系统的一致性要求，对于同样的搜索词，可以给出不同的搜索结果集合，只要搜索结果集合满足一定的精准性和相关性即可；而电子商务中搜索平台其搜索业务的复杂度是非常高的，搜索计算不仅仅包括基于Lucene打分的召回排序，还要加入很多复杂的业务定制逻辑，例如考虑其搜索域中包含的商品信息质量、商家会员级别、历史成交情况、用户点击情况、并对集中在同一会员商家名下的商品还要做适量的衰减；其处理逻辑消耗的计算资源和内存资源很多，尤其例如接入了个性化搜索，还要考虑搜索用户画像中的相关搜索行为偏好，兴趣网络等等；通过降低搜索复杂度，可以使搜索平台在同样的搜索硬件资源下提升其处理搜索请求的并发能力，这是一种高效实用的技术应用场景；

发明内容

本发明所要解决的技术问题是克服现有技术的不足，提供一种基于特定策略降低搜索复杂度以应对超负荷搜索请求的方法，通过对收到的所有搜索请求进行不同的策略划分不同的用户群体，将其中对业务价值影响不大的搜索请求进行搜索复杂度的降低，降低的方法是去除搜索查询请求中的排序，降低召回量，从而降低其对搜索服务器性能的占用和提高搜索服务集群的吞吐能力，使其避免因大量突发的超负荷搜索请求导致整个服务集群无法服务。超负荷搜索请求是指搜索平台遇到超过其最大处理负荷的搜索并发请求导致系统负载Load Average指标增高。

为解决上述技术问题，本发明提供一种基于特定策略降低搜索复杂度以应对超负荷搜索请求的方法，包括如下步骤：

步骤1：标识搜索请求，即所有发往搜索服务集群的搜索请求都需要带上特定的用户标识，标识包括用户来源IP，用户登录的Cookie信息，Spider(爬虫引擎)标志位，所有搜索请求都会首先提交给一个搜索集群转发器(Dispatcher)处理；

步骤2：区分请求和附加处理策略标志，即搜索集群转发器(Dispatcher)会根据管理员配置好的策略规则，将这些搜索请求进行用户优先级区分，同时判断当前的搜索请求数量和服务器负载是否达到了触发浪涌应对的标准，区分不同的用户搜索请求并附加上特定的搜索处理策略标志，然后由Dispatcher转发给集群中某个搜索服务实例(Searcher)处理；

步骤3：分策略处理请求，即搜索集群中的某个搜索服务实例(Searcher)负责收到该搜索处理策略标志位的搜索请求后，根据该策略标志的不同进行相应的处理；

步骤4：返回结果，即搜索服务实例(Searcher)将处理完的搜索结果返回给搜索集群转发器(Dispatcher)，搜索集群转发器再返回结果给对应发起请求的搜索客户端；

步骤5：定期监控动态调整策略，即当搜索集群转发器(Dispatcher)定期扫描发现超负荷搜索请求减缓或加重的时候(负载和访问量的相关指标在界限值波动时)，则根据特定处理逻辑，进行波动处理，直至超负荷搜索请求结束，所有指标恢复正常；

步骤6：记录过程评估影响，即搜索系统会记录所有处理流程和涉及到的搜索请求信息，并在浪涌结束后，后台通过邮件的方式自动通知相关业务干系人，以评估降低搜索复杂度的影响范围。

所述步骤2中，还包括：

步骤2-1：设置策略规则，包括设定策略级别指标和设定区分用户处理规则；

所述设定策略级别指标是指：管理员会配置策略分为四个级别，从级别1到级别4，根据当前搜索请求数量和服务器负载来进行不同级别的调用，每个级别的数据阈值是可以由管理员根据策略级别指标进行人工配置；策略级别指标包括：当前对应索引的每秒搜索请求并发数，当前搜索集群中服务器的5分钟平均服务器负载(以Linux操作系统的LoadAverage 的参数值为参照)；

所述设定区分用户处理规则是指：管理员会区分用户设定不同的级别规则，将用户分为爬虫标识Spidername和用户标识Username，并设置在不同的策略级别上；

步骤2-2：1级策略处理，即当定期扫描搜索服务器负载后，如果当搜索请求数量超过系统预设最大容量值或搜索服务器负载的5分钟Load Average值大于服务器CPU总核数，即启动级别1级应对策略，该策略会在Dispatcher收到的所有用户标识中识别出带有Spidername 的搜索请求，将带有OtherSpider标志位的搜索请求过滤出来，然后在将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理，此时加入的搜索处理策略标志位为*A*；

步骤2-3：2级策略处理，即在定期扫描后,当搜索请求数量超过系统预设最大容量值或搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，即启动级别2级应对策略，该策略会在Dispatcher收到的所有用户标识中识别出所有带有爬虫标记的搜索请求，不再区分Spidername的优先级；然后在将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时将步骤2-2中的原对应添加的搜索标志位改为*B*；

步骤2-4：3级策略处理，即在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，即启动级别3级应对策略，该策略会在Dispatcher收到的用户Cookie信息中判断该用户是否属于对应业务平台的注册用户，如果判断该请求中用户并非平台注册用户，则该用户的 Username标识为Other，将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时逐级升级将步骤2-3中的原对应添加的搜索标志位改为*B*，同时将步骤2-2中的原对应添加的搜索标志位改为*C*；

步骤2-5：4级策略处理，即在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，即启动级别4级应对策略，该策略会在Dispatcher收到的所有用户请求后，将注册用户标识，也就是Username＝Login的用户请求中加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时将步骤2-4中的原对应添加的搜索标志位改为*B*，同时将步骤2-3中的原对应添加的搜索标志位改为*C*，同时将步骤 2-2中的原对应添加的搜索标志位改为*D*；

步骤2-6：逐级策略调档，即在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时， Dispatcher会按照顺序依次将步骤2-2,2-3,2-4,2-5中相应的搜索请求的搜索策略标志位从 *A*开始依次递进到*D*，直到除了业务系统注册用户(即Usernmae＝Login的用户)之外所有的用户请求后的搜索策略标志位全部为*D*，Cookie中可判断为系统注册用户的搜索请求策略标志位最高级别提升到*C*。

所述步骤3中，还包括：

步骤3-1：加载缓存，即Searcher收到带有特定搜索处理策略标志位*A*的搜索请求，根据该标志位，该搜索请求将会首先从当前Searcher的缓存中加载，如果缓存加载不到再另外进行重新搜索运算，通过缓存调用降低了搜索计算复杂度；

步骤3-2：单点有损服务，即Searcher收到特定搜索处理策略标志位*B*的搜索请求，根据该标志位，该搜索请求会进行单点有损服务，单点有损服务是指因为搜索集群中的搜索业务是采用分布式搜索机制，即一次搜索需要分别请求2个或2个以上Searcher搜索实例执行搜索请求后再进行合并处理，当Searcher启动单点有损服务后，即该Searcher不会再分别请求其他Searhcer实例，直接单点Searcher执行完毕后返回；

步骤3-3：降维简化，即Searcher收到特定搜索处理策略标志位*C*的搜索请求，根据该标志位，该搜索请求会进行降维有损服务，降维有损服务是指将用户的搜索请求的计算复杂程度进行降维简化，跳过部分耗时较长的业务逻辑，例如忽略自定义的打分排序，减少召回数量等业务逻辑处理；

步骤3-4：返回空结果，即Searcher收到特定搜索处理策略标志位*D*的搜索请求，根据该标志位，Searcher会直接拒绝该搜索请求，返回空搜索结果。

所述步骤5中，还包括：

步骤5-1：当在定期扫描后，Dispatcher发现当搜索请求数量小于或等于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值小于或等于服务器CPU总核数时，将当前所有对应的不同处理级别的搜索请求的特定搜索处理策略标志位进行降档，降档的规则为从*D*逐级下降到*C*，从*C*逐级下降到*B*，从*B*逐级下降到*A*；

步骤5-2：当在定期扫描后，Dispatcher发现当搜索请求数量仍然小于或等于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然小于或等于服务器CPU总核数时，将所有带有*A*的处理标志的搜索请求后的处理标志清除，转为正常搜索处理；

步骤5-3：按照步骤5-1,5-2重复执行规则，直到所有处理标志都被清除，即所有搜索请求均正常处理，如果在下一个定时扫描周期中，发现搜索请求数量大于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值大于服务器CPU总核数时，则将当前所有对应的不同处理级别的搜索请求的特定搜索处理策略标志位进行升档，降档的规则为从*C*上升到*D*，从*B*上升到*C*，从*A*上升到*B*。

所述步骤6中，还包括：

步骤6-1：搜索系统会记录相应搜索业务的干系人的电子邮件联系方式，通过整理汇总所有处理情况报告给相关干系人以评估影响范围；每次处理浪涌都会生成一份特定搜索请求处理报告

步骤6-2：搜索系统会记录当时对应策略级别的服务器CPU负载和搜索请求并发数量，并绘制成柱状对比图，添加到处理报告中；

步骤6-3：搜索系统还会记录当时对应策略级别的搜索请求的处理标志的变化情况，例如何时从*A*到*B*等变化历史情况，添加到处理报告中；

步骤6-4：该处理报告以邮件方式发送给对应业务的全体干系人；

所述步骤2-1中，设定策略级别指标为：

1:[200,24]；2:[250,24]；3:[300,24]；4:[400,32]；

即以第一个参数的含义为例，其表示1级策略的数据阈值为每秒请求超过200(包含200)， Cpu的5分钟平均服务器负载超过24，后面以此类推，这个参数可以支持动态配置的；

将区分用户处理规则设置如下：

1:[Spidername＝Other:*A*]；

2:[Spidername＝All:*A*]；

3:[Username＝Other:*A*]；

4:[Username＝Login:*A*]。

本发明所达到的有益效果:

(1)本发明中的搜索客户端所携带的用户标识信息会被用来作为对用户的评级，所有用户分类评级工作都在搜索平台中的Dispatcher完成，客户端无需在进行其他配置，即当高负荷搜索请求发生时，无需客户端干预，所有应对措施有搜索平台中的Dispatcher和Searcher 实例自动完成处理。

(2)本发明中对有损服务思想的应用采用了结合用户对业务影响的不同权重，不同范围和不同程度的有损服务方式相结合。不简单进行一刀切的熔断方式，而是采用阶梯型的逐级升降的有损服务方式来应对高负荷搜索请求，使业务收到有损服务影响的范围尽可能小。

(3)本发明对分布式搜索平台的特性进行了利用，利用减少并发节点召回的方式，采用单节点召回搜索结果来降低搜索复杂度。在高负荷情况下通过限制召回范围减少了计算复杂度，同时还保证了搜索精准性，相比直接拒绝超量的服务方式来说，对客户端更加友好。

(4)本发明提出了利用搜索请求中包含了基本Lucene查询和自定义业务打分排序两部分的计算需求，在高负荷情况下，提出了通过降维服务的思想，即搜索平台Searcher只完成包含基本Lucene查询的计算量，而舍弃自定义业务打分排序的计算。通过这种降维服务的方式，可以降低搜索复杂度并提高应对高负荷搜索请求的性能。

(5)本发明提出了在应对高负荷搜索请求后，将所有系统自动处理降低复杂度的详细过程通过处理报告的方式，发送给提前设定好的各业务干系人，使得业务干系人可以获知系统降低复杂度的影响范围，并评估对业务的影响。通过这种方式，管理员可以改进配置特定策略的方式，使整个搜索平台更好的应对高负荷的搜索请求，而不需要额外增加硬件服务器支出。

附图说明

图1为本发明的示例性实施例的方法流程简图。

具体实施方式

下面结合附图和示例性实施例对本发明作进一步的说明：

如图1所示，本发明包括如下步骤：

步骤1：标识搜索请求

所有发往搜索服务集群的搜索请求都需要带上特定的用户标识，标识包括用户来源IP，用户登录的Cookie信息，Spider(爬虫引擎)标志位，所有搜索请求都会首先提交给一个搜索集群转发器(Dispatcher)处理；

步骤2：区分请求和附加处理策略标志

搜索集群转发器(Dispatcher)会根据管理员配置好的策略规则，将这些搜索请求进行用户优先级区分，同时判断当前的搜索请求数量和服务器负载是否达到了触发浪涌应对的标准，区分不同的用户搜索请求并附加上特定的搜索处理策略标志，然后由Dispatcher转发给集群中某个搜索服务实例(Searcher)处理；

步骤3：分策略处理请求

搜索集群中的某个搜索服务实例(Searcher)负责收到该搜索处理策略标志位的搜索请求后，根据该策略标志的不同进行相应的处理；

步骤4：返回结果

搜索服务实例(Searcher)将处理完的搜索结果返回给搜索集群转发器(Dispatcher)，搜索集群转发器再返回结果给对应发起请求的搜索客户端；

步骤5：定期监控动态调整策略

当搜索集群转发器(Dispatcher)定期扫描发现超负荷搜索请求减缓或加重的时候(负载和访问量的相关指标在界限值波动时)，则根据特定处理逻辑，进行波动处理，直至超负荷搜索请求结束，所有指标恢复正常；

步骤6：记录过程评估影响

搜索系统会记录所有处理流程和涉及到的搜索请求信息，并在浪涌结束后，后台通过邮件的方式自动通知相关业务干系人，以评估降低搜索复杂度的影响范围。

所述步骤2中，还包括：

步骤2-1：设置策略规则，包括设定策略级别指标和设定区分用户处理规则

设定策略级别指标

管理员会配置策略分为四个级别，从级别1到级别4，根据当前搜索请求数量和服务器负载来进行不同级别的调用，每个级别的数据阈值是可以由管理员根据策略级别指标进行人工配置；策略级别指标包括：当前对应索引的每秒搜索请求并发数，当前搜索集群中服务器的5分钟平均服务器负载(以Linux操作系统的Load Average的参数值为参照)；例如设置如下：1:[200,24]；2:[250,24]；3:[300,24]；4:[400,32]。以第一个参数的含义为例，其表示 1级策略的数据阈值为每秒请求超过200(包含200)，Cpu的5分钟平均服务器负载超过24。后面以此类推，这个参数可以支持动态配置的。

设定区分用户处理规则

管理员会区分用户设定不同的级别规则，将用户分为爬虫标识Spidername和用户标识 Username，如Google和Bing的Spider优先级高，其他的Spider的优先级较低，则设置在不同的策略级别上，例如根据不同Username用户级别进行区分，分为注册用户Login和其他非注册用户Other。

举例设置如下：1:[Spidername＝Other:*A*]；

2:[Spidername＝All:*A*]；

3:[Username＝Other:*A*]；

4:[Username＝Login:*A*]

步骤2-2：1级策略处理

当定期扫描搜索服务器负载后，如果当搜索请求数量超过系统预设最大容量值或搜索服务器负载的5分钟Load Average值大于服务器CPU总核数，即启动级别1级应对策略，该策略规则已在步骤2-1中进行了预先定义，会在Dispatcher收到的所有用户标识中识别出带有 Spidername的搜索请求，并，以步骤2-1中举例的1级用户处理策略规则

“1:[Spidername＝Other:*A*]”为例，将带有OtherSpider标志位的搜索请求过滤出来，然后在将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理，此时加入的搜索处理策略标志位为*A*；

步骤2-3：2级策略处理

在定期扫描后,当搜索请求数量超过系统预设最大容量值或搜索服务器负载的5分钟 Load Average值仍然大于服务器CPU总核数时，即启动级别2级应对策略，以步骤2-1中举例的2级用户处理策略规则“1:[Spidername＝All:*A*]”为例，该策略会在Dispatcher收到的所有用户标识中识别出所有带有爬虫标记的搜索请求，不再区分Spidername；然后在将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时将步骤2-2中的原对应添加的搜索标志位改为*B*，这就图1中所说的逐级升级策略处理；

步骤2-4：3级策略处理

在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，即启动级别3级应对策略，以步骤2-1中举例的3级用户处理策略规则“3:[Username＝Other:*A*]”为例，该策略会在 Dispatcher收到的用户Cookie信息中判断该用户是否属于对应业务平台的注册用户，如果判断该请求中用户并非平台注册用户，则该用户的Username标识为Other，将这些请求后加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时逐级升级将步骤2-3中的原对应添加的搜索标志位改为*B*，同时将步骤2-2中的原对应添加的搜索标志位改为*C*；

步骤2-5：4级策略处理

在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，即启动级别4级应对策略，以步骤2-1中举例的4级用户处理策略规则“1:[Username＝Login:*A*]”为例，该策略会在 Dispatcher收到的所有用户请求后，将注册用户标识，也就是Username＝Login的用户请求中加入特定搜索处理策略标志位再交给相应的搜索集群服务实例进行处理,此时加入的搜索处理策略标志位为*A*，同时将步骤2-4中的原对应添加的搜索标志位改为*B*，同时将步骤 2-3中的原对应添加的搜索标志位改为*C*，同时将步骤2-2中的原对应添加的搜索标志位改为*D*；

步骤2-6：逐级策略调档

在定期扫描后，Dispatcher发现当搜索请求数量超过系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然大于服务器CPU总核数时，Dispatcher会按照顺序依次将步骤2-2,2-3,2-4,2-5中相应的搜索请求的搜索策略标志位从*A*开始依次递进到*D*，直到除了业务系统注册用户(即Usernmae＝Login的用户)之外所有的用户请求后的搜索策略标志位全部为*D*，Cookie中可判断为系统注册用户的搜索请求策略标志位最高级别提升到 *C*。

所述步骤3中，还包括：

步骤3-1：加载缓存

Searcher收到带有特定搜索处理策略标志位*A*的搜索请求，根据该标志位，该搜索请求将会首先从当前Searcher的缓存中加载，如果缓存加载不到再另外进行重新搜索运算，通过缓存调用降低了搜索计算复杂度；

步骤3-2：单点有损服务

Searcher收到特定搜索处理策略标志位*B*的搜索请求，根据该标志位，该搜索请求会进行单点有损服务，单点有损服务是指因为搜索集群中的搜索业务是采用分布式搜索机制，即一次搜索需要分别请求2个或2个以上Searcher搜索实例执行搜索请求后再进行合并处理，当Searcher启动单点有损服务后，即该Searcher不会再分别请求其他Searhcer实例，直接单点Searcher执行完毕后返回，减少搜索计算复杂度；但返回的搜索结果相对于正常的搜索处理结果会偏少，但仍然能满足绝大部分搜索请求有搜索结果返回；

步骤3-3：降维简化

Searcher收到特定搜索处理策略标志位*C*的搜索请求，根据该标志位，该搜索请求会进行降维有损服务，降维有损服务是指将用户的搜索请求的计算复杂程度进行降维简化，跳过部分耗时较长的业务逻辑，例如忽略自定义的打分排序，减少召回数量等业务逻辑处理，其返回的搜索结果相对于正常的搜索处理结果的精确性会有所偏差，但可保证一定程度相关性，降低了搜索计算复杂度；

步骤3-4：返回空结果

Searcher收到特定搜索处理策略标志位*D*的搜索请求，根据该标志位，Searcher会直接拒绝该搜索请求，返回空搜索结果，以降低系统负荷。

所述步骤5中，还包括：

步骤5-1：当在定期扫描后，Dispatcher发现当搜索请求数量小于或等于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值小于或等于服务器CPU总核数时，将当前所有对应的不同处理级别的搜索请求的特定搜索处理策略标志位进行降档，降档的规则为从*D*逐级下降到*C*，从*C*逐级下降到*B*，从*B*逐级下降到*A*；

步骤5-2：当在定期扫描后，Dispatcher发现当搜索请求数量仍然小于或等于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值仍然小于或等于服务器CPU总核数时，将所有带有*A*的处理标志的搜索请求后的处理标志清除，转为正常搜索处理；

步骤5-3：按照步骤5-1,5-2重复执行规则，直到所有处理标志都被清除，即所有搜索请求均正常处理，如果在下一个定时扫描周期中，发现搜索请求数量大于系统预设最大容量值或当搜索服务器负载的5分钟Load Average值大于服务器CPU总核数时，则将当前所有对应的不同处理级别的搜索请求的特定搜索处理策略标志位进行升档，降档的规则为从*C*上升到*D*，从*B*上升到*C*，从*A*上升到*B*。

所述步骤6中，还包括：

步骤6-1：搜索系统会记录相应搜索业务的干系人的电子邮件联系方式，因为通过降低搜索复杂来应对超负荷搜索请求会带来搜索精准度的一定损失，可能对业务造成影响，需要通过整理汇总所有处理情况报告给相关干系人以评估影响范围；每次处理浪涌都会生成一份特定搜索请求处理报告

步骤6-2：搜索系统会记录当时对应策略级别的服务器CPU负载和搜索请求并发数量，并绘制成柱状对比图，添加到处理报告中；

步骤6-3：搜索系统还会记录当时对应策略级别的搜索请求的处理标志的变化情况，例如何时从*A*到*B*等变化历史情况，添加到处理报告中；

步骤6-4：该处理报告以邮件方式发送给对应业务的全体干系人。

换言之，本发明就是为了针对现实的技术应用场景，通过特定的策略对用户进行识别和区分，搜索平台所有收到的搜索请求都是包含有用户Cookie，IP，爬虫标志位信息；通过这些信息可以区分出用户的不同级别，通过划分用户的不同级别，就可以设定面对超负荷搜索请求下的不同应对策略级别；并且针对这些不同应对策略级别还可以加入不同的应对处理标志；将这些应对处理标志附加在搜索平台的对应搜索请求后，就可以让搜索平台进行区分处理，进行不同程度上的复杂度降低；

搜索复杂度降低可以通过调用缓存、减少并发收集节点、减少搜索请求自定义排序计算来实现；配合对应不同用户群体的区分，而不是采用一刀切的方式，可以将有损服务的涉及范围控制在最小影响程度下；同时通过设定特定的策略方式，可以让搜索复杂度降低的程度也跟随搜索请求并发负荷情况进行动态的调整；即超负荷请求持续周期内增加，则提高搜索复杂度降低的程度和范围，当超负荷请求持续周期内减少，则降低搜索复杂度降低的程度和范围；直至最后完全退出降低搜索复杂度应对干预，并将本次应对干预的情况通过处理报告的方式发给相关业务干系人；

本发明主要用于提供一种基于特定策略降低搜索复杂度以应对超负荷搜索请求的方法，其有益效果在于：

(1)本发明中的搜索客户端所携带的用户标识信息会被用来作为对用户的评级，所有用户分类评级工作都在搜索平台中的Dispatcher完成，客户端无需在进行其他配置，即当高负荷搜索请求发生时，无需客户端干预，所有应对措施有搜索平台中的Dispatcher和Searcher 实例自动完成处理。

(2)本发明中对有损服务思想的应用采用了结合用户对业务影响的不同权重，不同范围和不同程度的有损服务方式相结合。不简单进行一刀切的熔断方式，而是采用阶梯型的逐级升降的有损服务方式来应对高负荷搜索请求，使业务收到有损服务影响的范围尽可能小。

(3)本发明对分布式搜索平台的特性进行了利用，利用减少并发节点召回的方式，采用单节点召回搜索结果来降低搜索复杂度。在高负荷情况下通过限制召回范围减少了计算复杂度，同时还保证了搜索精准性，相比直接拒绝超量的服务方式来说，对客户端更加友好。

(4)本发明提出了利用搜索请求中包含了基本Lucene查询和自定义业务打分排序两部分的计算需求，在高负荷情况下，提出了通过降维服务的思想，即搜索平台Searcher只完成包含基本Lucene查询的计算量，而舍弃自定义业务打分排序的计算。通过这种降维服务的方式，可以降低搜索复杂度并提高应对高负荷搜索请求的性能。

(5)本发明提出了在应对高负荷搜索请求后，将所有系统自动处理降低复杂度的详细过程通过处理报告的方式，发送给提前设定好的各业务干系人，使得业务干系人可以获知系统降低复杂度的影响范围，并评估对业务的影响。通过这种方式，管理员可以改进配置特定策略的方式，使整个搜索平台更好的应对高负荷的搜索请求，而不需要额外增加硬件服务器支出。

以上实施例不以任何方式限定本发明，凡是对以上实施例以等效变换方式做出的其它改进与应用，都属于本发明的保护范围。