1号店号店11.11：分布式搜索引擎的架构实践：分布式搜索引擎的架构实践
“11.11”是一年一度的电商盛宴，为了准备这个一年内最大规模的促销，1号店各条战线都在紧张有序地忙碌着。1号店搜索团
队经过几年的大促历练，不断推动架构演进，积累了越来越多的经验。
11.11的主要特点是流量大和突发性高，这就带来了两个核心的需求：
可扩展 如何抗住这样的流量，针对这个需求，1号店搜索团队构建了分布式搜索引擎，支持横向扩展；并且针对业务特点做了
Routing优化，让搜索的效率更高。
快速响应 流量越大，单位时间内的流量价值就越大，出现问题的损失也就越大，如何做到快速响应变得非常关键。针对这个
需求，搜索系统支持自动部署和快速扩容以应对突发流量，索引数据从导入、处理到上线服务会经过层层验证，同时还有监控
体系及时发现线上的问题。
下面我们针对这些设计要点分别展开。
分布式搜索引擎1号店分布式搜索引擎是Lucene/Solr核心的，结合SOA框架Hedwig构建了一层分布式框架，支持搜索请求的
分发和合并，并且构建了搜索管理后台，支持多索引管理、集群管理、全量索引切换和实时索引更新。
选择自己构建分布式方案，而不是采用开源的SolrCloud或ElasticSearch，主要是基于以下几点考虑：
（1） ElasticSearch/SolrCloud都适合于把搜索引擎作为一个黑盒系统来使用，而1号店搜索业务的展现形式多样性很高，搜
索条件有的会很复杂，有的需要通过自定义插件来实现，性能调优时也需要对引擎内部的执行细节进行监控。
（2） 将ElasticSearch/SolrCloud与公司内部的发布系统、监控系统和SOA体系结合起来，也是一项比较耗时的工作。
（3） 相对于整体使用，我们更倾向于把Lucene/Solr开源家族中的各个组件按需引入，一方面降低引入复杂工程的可维护性
风险，另一方面逐渐深入理解这些组件，可以在必要时替换为定制化的组件。
分布式搜索是为了解决数据增长过程中索引变大和操作时间变长的问题，它将原来的单个索引文件划分成n个切片(shards)，
让每个shard都足够小，从而保证索引可以在多台服务器上部署，而且搜索操作可以在较短时间内返回。
如上图所示，分布式搜索中有两个主要组件：Shard Searcher和Broker，其中Shard Searcher与单机搜索引擎类似，基于
Lucene/Solr完成基本的搜索任务。Broker负责把针对整个索引的搜索请求转化为针对单个Shard的搜索请求，它把Shard搜索
请求分发给各个ShardSearcher，并且把各个Shard的结果进行合并，生成最终的结果。
分布式搜索中，一次搜索所需的资源与它要访问的Shard数和每个Shard要返回的结果数有非常强的关联关系，在Shard数特
别多或结果数特别多时可能会碰到一些的内存、CPU资源使用的问题。针对结果数特别多的情况，可以按照业务场景优化，
比如如果对排序无要求，就可以每次指定一个Shard进行搜索，搜完这个Shard再换下一个，这样就限制了每次搜索的Shard
数，另一方面也可以考虑使用DeepPaging等技术，减少每次Shard搜索的成本。我们下一小节也会介绍1号店主站搜索是如何
减少每次搜索Shard数的。
另外，上图中的Broker和Shard Searcher仅仅是概念上的划分，实际部署时有几种选择：
A) 每个节点上都有Broker和部分Shard的Shard Searcher。
B) Broker单独部署成一个集群，与Shard Searcher隔离。
C) Broker作为客户端的一部分，和搜索应用一起部署。
我们开始使用的是A方式，后来主站搜索转为C方式，主要是考虑到可以节省一次网络调用（以及请求和结果的序列化开
销），另外Broker在客户端也可以更多地使用应用逻辑相关的数据进行更高效的Routing。
高效Routing通过前面的讲述，我们不难看出，使用分布式搜索引擎，面临的核心问题就是如何选择高效的Sharding策略和
Routing方案。为了设计Routing方案，我们需要深入理解业务场景。
1号店有很多的类目，每个类目的业务模式也不尽相同。以图书和快消品为例，图书是一种典型的长尾商品，它需要索引大量
评论0