搜索接口优化方法简述

内容纲要

背景

微医搜索系统是以接口的形式提供服务的。任何业务方需要搜索的服务,搜索会从各个数据源获取数据,同步进solr或者es这种数据载体之中。虽然es和solr都有各自的api,但是对用户来说并不友好,并且无法做一些业务逻辑。因此,搜索会在这些api外层继续封装一层接口提供服务。
所以,对外暴露的接口就是用户的访问数据源的渠道。它的响应速度直接影响着用户的服务。

优化方向

搜索对响应时间的优化可以从两个方面来看,一个是硬件,一个是软件。

硬件

硬件方面可以从两方面优化,一个是增加服务器的数量,一个是提高服务器的性能。

增加服务器数量

增加服务器的数量,搜索可以进行一个业务隔离。这就好比数据库,多个数据库实例布置在一套集群上,互相之间是可以互相影响的。增加服务器最大的好处,是可以把重要的服务隔离,减少互相之间的影响,提高服务的稳定性,从而降低接口响应时间。
增加服务器还有另外一种操作,可以做成双机房的形式。把业务流量分散到2个不同的机房,降低单集群的压力,以此达到降低接口响应时间的目的。

提升服务器性能

搜索系统是一个很占用内存的系统。
同时,为了保证数据的一致性,搜索系统有recovery这个保护操作(简单的说,就是如果集群间数据版本差异较大,服务器之间会停止服务,重新同步数据)。因此,recovery操作的直接影响就是,暂停了recovery的服务器对外提供服务的能力。recovery是一个同步数据的过程,所以服务器的带宽影响着recovery的时间。如果服务器之间的传输速度提高了,那么出现recovery问题的,同步时间也会减少,减少对服务的影响时间。
最后,搜索更多的数据是存在磁盘上的,搜索系统不仅需要和缓存交换数据,更需要和磁盘有大量的交互。提升磁盘的io同样是硬件的优化方向之一。
综上所述,在降低服务起响应时间方面,服务器可以从增加缓存,更换固态硬盘,增加高速率带宽的网卡和交换机三个方面进行优化。

软件

从软件方面要优化搜索的接口首先需要了解搜索的流程。搜索从数据流程方面可以分为建索引和查询2个阶段。所以在软件方面,可以分成架构,索引和查询三个方面考虑优化。

架构

搜索的查询是涉及磁盘的io和内存的使用。服务在构建大批量索引的时候,搜索系统的大部分资源被用来处理集群数据了,还可能会recovery。这个时候如果提供服务,响应时间会提升。所以,从架构方面需要优化的有2方面,一方面隔离索引和查询的服务器,减少索引服务器查询和构建索引的互相影响。另一方面,可以错开建索引和查询的时间。把大批量更新索引数据的服务器放在查询量少的时间段执行,比如凌晨的时间。从而降低建索引对查询时间的影响。

索引

索引对查询的影响主要是在两个方面。单个索引的大小,还有索引的频率。如果短时间内业务方更新了大批量的数据更新,而搜索只构建了一个文档。意味着提交的文档非常大,文档数非常多,那么服务器接受的压力也很大。搜索的实时监控,是监控到一条数据,就更新一条数据,这样一来,服务器要不停的刷新索引,重复的构建索引,导致数据更新变慢,查询速度同样变慢。这种情况下,我们需要问业务方的需求,能否把一些数据的服务减少到批量更新。
所以,在索引段的优化,一个方面是减少单个索引的大小,一方面是降低索引的频率。从这两方面优化索引。

查询

查询部分是最关键也是最直接的优化内容。我们会从查询的参数,缓存,拆分shard,路由机制,外部依赖五个方面进行优化。

查询的参数优化

搜索查询的过程中,主要是fq的优化。fq的查询原理是先把每个fq的文档从luence中过滤出来,然后把所有的fq过滤的文档去重组合起来返回用户。组合的过程非常耗时。由于用户查询的条件是比较固定的,这时候可以把fq的条件组合到一起进行查询。在luence底层就做这么一个查询,而不需要组合查询。做过一个实验,把fq条件组合到一起查询能够把响应时间医生37倍,效果非常明显。

缓存的优化

搜索查询的过程中,搜索系统是自带缓存策略的。由于数据的更新,搜索需要不断的更新缓存。每次更新的缓存如果存在期很短,那么命中率也不会高,对待新的查询很难有好的表现。为了应对这些问题,搜索系统对于缓存有着一套预热的机制。在每次缓存需要重新更新的时候,可以从原有的缓存中获取一定的查询缓存进行预热。这样就不需要每次都去重新更新了。这样的方式,可以在fq优化后的基础上进一步优化3倍。但是也会带来一个问题,实时数据的更新性能会下降。预热的时间会延缓新数据的展示时间。
因此,基于搜索系统的缓存优化适合实时性低的接口优化使用。

拆分shard

一个索引十分大的时候,查询数据的量级也是很大的。solr针对每个collection,有一个shard机制。也就是一个业务的collection,你可以把它进行分片,相当于一个大的collection拆分成了小的块儿进行查询,从而提高响应速度。比如一个查询大部分请求有一个固定查询,性别查询。我们就可以把性别作为一个区分shard的标准,分成2个块儿。这样,每次请求进来,只需要查询固定的shard的即可。这种效果提升非常明显。
另外,如果没有明显的区分条件,分shard的效果具有两面性。一方面,由于要从各个shard获取数据并且合并,所以平均查询时间会变长。但是,接口的稳定性却提高了不少。99%的索引查询完成时间降低了。这说明,在提高平均响应时间的同时,它把那些“查询毛刺”也给降低了。
分shard还有一个好处,可以降低但块儿数据的索引量。那么当发生recovery的时候,它可以降低那么当发生recovery的时候的时间。

路由机制

在solr中,每个collection是分布在不同的服务器中的。但是不论哪个服务器,都能够响应服务的,但是中间会涉及一个转发的过程。这时候,如果我们知道每个节点的状态,可以直接把请求直接发送到leader节点或者拥有分片的服务器,从而降低服务的响应时间。

外部依赖

如果一些索引不仅查询的条件一致,连查询的值也是一致的。我们可以在外部,通过已有的中间件(codis,redis等)进行外部缓存处理,如果进来的url匹配上了,直接返回而不走搜索系统,从而降低响应时间。但是这种方式要充分考虑使用场景,否则,会极度加大中间件的压力。

总结

综上所述,我们从软件,硬件2个大方面展开,讲了搜索接口的主要优化方向和方法,其中着重介绍了查询端的五个方法。通过上述方法的不断优化,大部分搜索接口对比最开始的响应超时率能够提升百倍甚至上千倍。目前,我们的核心接口3s超时率都在十万分之一以下。

发表评论

电子邮件地址不会被公开。 必填项已用*标注