详谈京东的商品搜索系统架构设计

详谈京东的商品搜索系统架构设计

• 来源:网络
• 更新日期:2020-07-30

摘要： 京东商品搜索引擎是搜索推荐部自主研发的商品搜索引擎，主要功能是为海量京东用户提供精准、快速的购物体验。虽然只有短短几年的时间，我们的搜索引擎已经经过了多次618店庆

京东商品搜索引擎是搜索推荐部自主研发的商品搜索引擎，主要功能是为海量京东用户提供精准、快速的购物体验。虽然只有短短几年的时间，我们的搜索引擎已经经过了多次618店庆和双11的考验，目前已经能够与人们日常使用的如谷歌、百度等全文搜索引擎相比，我们的产品与其有相通之处，比如涵盖亿级别商品的海量数据、支持短时超高并发查询、又有自己的业务特点：

海量的数据，亿级别的商品量；

高并发查询，日PV过亿；

请求需要快速响应。

搜索已经成为我们日常不可或缺的应用，很难想象没有了Google、百度等搜索引擎，互联网会变成什么样。京东站内商品搜索对京东，就如同搜索引擎对互联网的关系。

他们的共同之处：1. 海量的数据，亿级别的商品量；2. 高并发查询，日PV过亿；3. 请求需要快速响应。这些共同点使商品搜索使用了与大搜索类似的技术架构，将系统分为：1. 离线信息处理系统；2. 索引系统；3. 搜索服务系；4.反馈和排序系统。

同时，商品搜索具有商业属性，与大搜索有一些不同之处：1. 商品数据已经结构化，但散布在商品、库存、价格、促销、仓储等多个系统；2. 召回率要求高，保证每一个正常的商品均能够被搜索到；3. 为保证用户体验，商品信息变更（比如价格、库存的变化）实时性要求高，导致更新量大，每天的更新量为千万级别；4. 较强的个性化需求，由于是一个相对垂直的搜索领域，需要满足用户的个性化搜索意图，比如用户搜索“小说”有的用户希望找言情小说有的人需要找武侠小说有的人希望找到励志小说。

另外不同的人消费能力、性别、对配送时间的忍耐程度、对促销的偏好程度以及对属性比如“风格”、“材质”等偏好不同。以上这些需要有比较完善的用户画像系统来提供支持。

总体架构图

搜索服务集群：由很多个merger节点组成的集群。接收到查询query后，将请求通过qp触发有策略地下发到在线检索服务集群和其他服务集群，并对各个服务的返回结果进行合并排序，然后调用detail server包装结果，最终返回给用户。

query processor server：搜索query意图识别服务。

在线检索服务集群：由很多个searcher节点组成，每个searcher列对应一个小分片索引（包含全量数据和实时增量数据）。

detail server：搜索结果展示服务。

索引生产端：包含全量和增量数据生产，为在线检索服务集群提供全量索引和实时索引数据。

离线信息处理系统

由于商品数据分布在不同的异构数据库当中有KV有关系型数据库，需要将这些数据抽取到京东搜索数据平台中，这分为全量抽取和实时抽取。

对于全量索引，由于商品数据散布于多个系统的库表中，为了便于索引处理，对多个系统的数据在商品维度进行合并，生成商品宽表。然后在数据平台上，使用MapReduce对商品数据进行清洗，之后进行离线业务逻辑处理，最终生成一份全量待索引数据。

对于实时索引，为了保证数据的实时性，实时调用各商品信息接口获取实时数据，将数据合并后采用与全量索引类似的方法处理数据，生成增量待索引数据。

索引系统

此系统是搜索技术的核心，在进入这个系统之前，搜索信息仍然是以商品维度进行存储的。索引系统负责生成一种以关键字维度进行存储的信息，一般称之为倒排索引。

此系统对于全量和增量的处理是一致的，唯一的区别在于待处理数据量的差异。一般情况下，全量数据索引由于数据量庞大，采用Hadoop进行；实时数据量小，采用单机进行索引生产。

搜索服务系统

搜索服务系统是搜索真正接受用户请求并响应的系统。这个系统最初只有1列searcher组成在线检索服务。由于用户体验的需要，首先增加Query Processor服务，负责查询意图分析，提升搜索的准确性。随着访问量的增长，接着增加缓存模块，提升请求处理性能。接着随着数据量（商品量）的增长，将包装服务从检索服务中独立出去，成为detail server服务。数据量的进一步增长，对数据进行类似数据库分库分表的分片操作。这时候，在线检索服务由多个分片的searcher列组成。自然而然，需要一个merger服务，将多个分片的结果进行合并。至此，搜索基础服务系统完备。

之后，无论是搜索量的增长或者数据量的增长，都可以通过扩容来满足。对于618、1111之类的搜索量增长，可通过增加每个searcher列服务器的数量来满足。而对于商品数据的不断增加，只需要对数据做更多的分片，相应地增加searcher列来满足。

搜索服务系统内部的处理流程如下：

在这个流程中，缓存模块和拉取结果模块非常稳定。而排序模块和在线业务逻辑处理模块经常需要改动。架构需要稳定，高效和通用。排序业务特点是实验模型多，开发迭代速度快，讲求效果。为了解决这一冲突，需要将排序业务与架构分离，以动态链接库的方式集成到搜索整体架构中，具体包括文本策略和其他策略两个维度的相关性，文本策略相关性集成在searcher当中；其他策略相关性（包括反馈，个性化和业务调权等等）集成在merger当中。实现架构与排序业务各司其职，互不影响干扰。