电商搜索系统存在以下特点：
数据量庞大。（上亿级别）
高并发。（日均pv过亿、数十亿）
一条商品数据由商品基本信息、价格、库存、促销、评价等组成，这些数据存储在各自业务系统当中。（多数据源导致构建索引比较麻烦）
召回率要求高。（哪个商家发现搜不到自家的商品肯定要抓狂，哪怕有一个搜不到。）
时效性要求高，价格变动、库存变动、上下架等要求近实时。（更新时间过长虽然不会造成资损，但是会严重影响用户体验）
索引更新量庞大。（上千万级别）
排序！排序！排序！如何把用户最想要的排在前面，提升转化率，是搜索的核心价值。
个性化排序。对用户进行画像，然后抽取特征项参与排序。你对风格、材质、价格、品牌等因素的偏好都会影响排序结果。（千人千面）
京东搜索系统架构图如下：
关键点解读：
1）搜索分片、副本集
副本集：随着并发量越来越大，单机已不能胜任，可以考虑“横向扩展”（副本集）做负载均衡，提升整个搜索平台的并发能力。
分片：随着数据规模越来越大，单机的内存、计算资源吃紧，造成单次请求响应超时，可以考虑分片，将大索引切分成小索引，从而满足单机的性能。
将分片、副本集综合起来构建分布式搜索引擎，不管以后是搜索量增长还是数据量增长，都可以通过扩展来满足。
2）索引过程（全量索引、增量索引）
全量索引数据准备：上文提到“搜索系统中一条商品数据由商品基础信息、价格、库存、促销、评价等信息组成，这些数据都分布在不同的业务系统中”。为了便于索引处理，对多个系统的数据进行合并，生成商品宽表。然后在数据平台上对数据进行清洗，形成一份待全量索引数据。
全量索引：由于全量数据比较庞大，采用hadoop进行“并行”处理。其实全量索引重点就是分布式索引，简单方式可以根据一个数据切分规则，把数据分解成n块（n对应分片数），由不同的机器同时构建索引。如下图：
增量索引：接受MQ消息，然后实时调用各个业务接口建立索引。
3）检索
一个检索请求过来，先到merger，由merger将检索请求分发给各个searcher节点，searcher节点进行检索并返回结果给merger，然后merger进行合并排序，最后返回。
那么这里涉及两次排序，第一次是在searcher里面排序，第二次是在merger做合并排序。（排序后面具体再说）
4）排序
上文提到一次搜索过程存在两次排序：search排序，merge排序。
searcher排序注重文本策略，这里主要包括文本域、价格、销量、好评等“商品综合分”排序。
merger排序根据多个结果集进行合并排序，主要包括：店铺多样性、品牌多样性、战略扶持品牌等业务规则。
各大电商公司的排序都不太一样，也会有“排序白皮书”供卖家进行参考，作为站内排序优化的参考书。
排序是电商搜索引擎的核心！
5）个性化搜索
个性化之前的搜索对于同一个查询，不同用户看到的结果是完全相同的。这可能并不符合所有用户的需求。在商品搜索中，这个问题尤为特出。因为商品搜索的用户可能特别青睐某些品牌、价格、店铺的商品，为了减少用户的筛选成本，需要对搜索结果按照用户进行个性化展示。
个性化的第一步是对用户和商品分别建模，第二步是将模型服务化。有了这两步之后，在用户进行查询时，merger同时调用用户模型服务和在线检索服务，用户模型服务返回用户维度特征，在线检索服务返回商品信息，排序模块运用这两部分数据对结果进行重排序，最后给用户返回个性化结果。
6）扩展搜索范围（Query Processer）
整合搜索用户在使用搜索时，其目的不仅仅是查找商品，还可能查询服务、活动等信息。为了满足这一类需求，首先在Query Processor中增加对应意图的识别。第二步是将服务、活动等一系列垂直搜索整合并服务化。一旦QP识别出这类查询意图，就条用整合服务，将对应的结果返回给用户。
7）其他
缓存设计（分级缓存）
Detail Server（补充展示字段）
以上内容整理自：
京东11.11 - 商品搜索系统架构设计
转载于：https://www.cnblogs.com/huangfox/p/5111713.html
