京东亿级商品搜索核心技术解密(2)

搜索请求流程如下：

1. 外部请求通过vip到达blender；
2. Blender调用QP,QP调用运营平台,其中运营平台主要负责将日常运营数据服务化,QP负责分析query；
3. Blender同时请求Merger和其他垂直搜索服务；
4. Merger调用UserProfile获取用户标签信息；
5. Merger将请求发给每列searcher；
6. 每个searcher召回商品并返给Merger；
7. Merger合并多列searcher的结果,确定需要输出的商品,请求Datail包装对应的商品信息；
8. Detail包装商品信息返给Merger；
9. Merger将包装好的商品返给blender；
10. Blender将merger返回的结果与其他垂直搜索结果进行合并,最终返回给前端.

Blender、Merger、Searcher和Detail是整个系统的核心组件,它们之间的调用关系由Clustermap管理.各个模块将自己的服务注册到ClusterMap,同时从ClusterMap订阅其调用模块的信息来确定实际调用关系.

简要搜索服务流程,如下图所示(搜索服务系统内部处理流程)：

图中名词解释如下：

• Page cache：页面缓存,blender模块直接缓存输出的页面,merger缓存了多页商品id；
• Attr cache：属性缓存,缓存的搜索属性导航区的数据；
• Doc cache：缓存查询词从全量索引召回的结果；
• OP：运营平台服务,负责搜索运营数据的服务化；
• QP：query processor,负责query意图识别.

用户请求发送到blender,首先解析参数.如果命中blender page cache直接返回给用户.如果没有命中,则调用运营平台服务(OP)和QP,并将其传给Merger,Merge会检查是否命中Attr cache,如果命中并且恰好仅请求属性汇总结果,直接返回给blender.否则进一步查看是否命中merger page cahce,如果命中直接调用detail包装,返给blender.如果没有命中,则调用User Profile获取用户标签,将其传给searcher(篇幅所限,图中只列了一个searcher,实际是多个).Searcher接到请求,判断是否命中doc cache,如果命中doc cache,则拉取增量结果；如果没有命中doc cahe,则拉取全量和增量结果.然后依次进行排序、在线业务处理,把结果返给merger.Merger合并多个searcher结果,排序、在线业务处理,最后调用detail包装,最后将结果返给blender,blender合并多个搜索结果后返回给用户.

作为一个高并发系统,为了保证高召回率和低响应延时,我们把整个搜索服务流程的处理全部放在内存当中进行计算.多个searcher并发处理请求,同时单个searcher内部采用线程池技术,即所有线程之间共享倒排索引和商品属性信息,提高内存使用效率；每个查询使用一个独立线程串行执行,保证并发的多个查询线程之间互不影响.此外通过合理的设置线程池的大小,我们可以保证系统的CPU资源得到充分利用.在上述两个方面对系统进行优化之后,整个搜索服务系统的稳定性、召回率、内存使用率、计算速度等指标都有大幅度的提高.但是我们改进系统的步伐并没有停歇,因为通过实践发现基于内存和线程池的搜索服务仍然有几个瓶颈点亟需解决,主要包括：拉取倒排、排序和在线业务处理.针对这些问题,我们进行了二次优化,主要包括如下措施：

1. 多级缓存策略

1. Blender Page cache：由于搜索符合互联网的二八法则,20%热门查询频度非常高,占每天搜索请求量80%.针对这一特点,搜索第一级缓存以查询请求为key,将返回给用户的页面作为value.对于完全相同的请求,直接从缓存返回结果.页面缓存策略上线伊始,缓存命中率就接近了30%,基本解决了当时的性能问题.
2. Merge Page cache：随着业务的发展,排序结果需要针对不同用户实现个性化订制,这就导致请求中会包含用户的user pin.如果直接将user pin放入缓存作为key,会导致blender cache的key数量暴增,不但需要超大的缓存空间,同时缓存的命中率也会极低,最终会导致线上个性化服务的体验满意度降低.为了解决这个问题,将user_pin加入key,但是value只保存排序好的商品id,这样需要的缓存空间远远小于blender cache.当命中缓存后,调用detail直接进行结果包装.为了进一步提高缓存命中率,利用用户搜索的翻页习惯,即离线统计出用户的翻页数TP99,然后在value中缓存这些页面涉及到所有的商品id,从实践效果来看,用户后续的翻页请求大部分会命中cache.
3. 在深入分析了业务和排序的需求之后,我们发现拉取倒排的结果只和“查询词&筛选条件”有关,而与用户无关,因此可以按照“查询词&筛选条件”作为key的方式对其进行缓存.

虽然拉取倒排结果缓存的key很快就解决了,但是我们在解决Value的存储时遇到了两个问题：1)拉取倒排的结果非常之多,导致缓存过大；2)对此结果缓存,会降低实时索引的时效性.

对于问题1),在分析了业务之后,对需要缓存的信息进行了大量的精简并采用压缩存储,最终将一个查询的缓存控制在0.5M以下.

（编辑：ASP站长网）