搜索引擎优化宝典(《揭秘双十一背后的技术较量》专题解读之两个篇)

　　搜索引擎优化宝典(《揭秘双十一背后的技术较量》专题解读之两个篇)

　　“11.11”是一年一度的电商盛宴。为了准备今年最大的促销活动，一号店的各条战线都忙碌而有序。经过几年的大促经验，一号店搜索团队不断推动架构的演进，积累了越来越多的经验。

　　此外，ArchSummit全球建筑师峰会北京站将于2015年12月18日-19日在北京国际会议中心举行。大会设置了“揭开双十一背后的技术大赛”专题，解读双十一背后的技术。十一。故事，欢迎关注。

　　11.11的主要特点是流量大、突发性高，带来两个核心需求：

　　下面，我们将分别展开这些设计点。

　　分布式搜索引擎

　　一号店分布式搜索引擎是Lucene/Solr的核心，结合SOA框架Hedwig构建了一层分布式框架，支持搜索请求的分发和合并，并搭建搜索管理后台，支持多索引管理、集群管理、全索引切换和实时索引更新。

　　选择自己构建分布式解决方案，而不是使用开源的 SolrCloud 或 ElasticSearch，主要基于以下考虑：

　　（1） ElasticSearch/SolrCloud都适合作为黑盒系统使用搜索引擎，而一号店搜索业务的展示形式非常多样，有些搜索条件会很复杂，有些需要通过定义插件来实现这一点，您还需要在性能调优期间监控引擎内部的执行细节。

　　（2） 将ElasticSearch/SolrCloud与公司内部发布系统、监控系统和SOA系统结合起来也是一项耗时的工作。

　　（3）相比整体使用，我们更倾向于按需引入Lucene/Solr开源家族中的各个组件。一方面降低了引入复杂项目的可维护性风险。另一方面，我们逐渐了解这些组件。必要时可以用自定义组件替换。

　　分布式搜索是为了解决数据增长过程中索引变大，运算时间变长的问题。它将原来的单个索引文件分成n个片（shards），使每个shard足够小，保证索引可以在多个部署在一台服务器上，并且搜索操作可以在短时间内返回。

　　

　　如上图所示，分布式搜索主要有两个组件：Shard Searcher和Broker。Shard Searcher类似于一个独立的搜索引擎，基于Lucene/Solr完成基本的搜索任务。Broker 负责将整个索引的搜索请求转换为单个分片的搜索请求。它将分片搜索请求分发给每个 ShardSearcher，并结合每个分片的结果生成最终结果。

　　在分布式搜索中，一次搜索所需的资源与要访问的分片数量和每个分片返回的结果数量有很强的相关性。当分片数量或结果数量特别多时，会出现一些内存和 CPU 资源使用问题。在结果数量特别多的情况下，可以根据业务场景进行优化。例如，如果没有排序要求，可以指定每次搜索一个shard，搜索完后替换下一个shard，这样就限制了每次搜索的shard个数。另一方面，也可以考虑使用 DeepPaging 等技术来降低每次 Shard 搜索的成本。下一节我们还将介绍一号店主站搜索如何减少每次搜索的分片数。

　　另外，上图中的Broker和Shard Searcher只是概念上的划分，实际部署有几种选择

　　A) 每个节点上带有 Broker 和一些 Shard 的 Shard Searcher。

　　B) Broker 单独部署为一个集群，与 Shard Searcher 隔离。

　　C) Broker 作为客户端的一部分与搜索应用程序一起部署。

　　我们从A方法开始，后来master search改成了C方法，主要是考虑可以节省一次网络调用（以及请求和结果的序列化开销），Broker也可以在上面使用更多的应用逻辑客户端。用于更有效路由的相关数据。

　　高效路由

　　通过前面的描述不难看出，在使用分布式搜索引擎时，核心问题是如何选择高效的分片策略和路由方案。为了设计一个路由解决方案，我们需要深入了解业务场景。

　　一号店有很多品类，每个品类都有不同的商业模式。以图书和快消品为例，图书是典型的长尾商品，需要索引大量的SKU（Stock Keeping Unit，可以理解为一个独立的商品），但访问量而且每个SKU的销量都不一样。高的; 快消品是另一个极端，整体SKU数量不高，但流量和效率都很高。这造成了不平衡的局面。图书SKU数量占比50%以上，但流量不足10%。我们首先排除了基于分片数量（id mod N）的平衡划分策略。

　　1号店搜索主要有两个入口，一个是搜索框中的搜索词，一个是分类导航。在这两个门户中，点击某个类别必须是访问特定的一级类别，而用户在搜索单词时只会关注几个相关的类别。基于这种访问方式，我们采用了按类别分片的策略。基本操作是：

　　(1） 根据一级类别划分分片。

　　(2）如果分片太大，会继续按照二级分类进行划分。

　　(3） 前两步之后，如果分片的shard太小，会根据相关性合并shard。

　　经过这样的尝试，分片策略就确定了。分片后的分片索引大小一般为200~500MB，单次搜索分片可以控制在10ms以内。

　　接下来，说到Routing，我们还有两个场景：词搜索和分类导航。对于分类导航，原理很简单。根据类别ID找到分片策略，就可以确定要访问的分片，虽然在现实中需要考虑扩展类别等特殊场景，但是做一个简单的路由策略并不难。另外，类别数量有限，路由规则可以缓存在broker的本地内存中。

　　词搜索场景要复杂得多，根据词本身很难判断它属于哪个分片。我们首先根据词的流行度将它们分为两类，并采用不同的路由策略。对于热词，搜索词流量也符合80-20法则。20%的热词占据了80%的搜索流量。对于热词，建立索引后，我们可以运行热词搜索，记录下那些 Shards 有的，结果，热词路由表是离线构建的。切换索引时，路由表也会一起加载。对于非热词，使用第一次搜索访问所有分片，根据结果记录路由表。该词将被缓存以供下次搜索。

　　基础路由策略上线后，通过监控各个分片的流量，我们发现了一个新的问题。图书类别的流量远高于应有的流量。仔细分析后发现，由于书籍类别的特殊性，书籍中可以找到很多单词。但是，这些结果一般都不是用户想要的，实际上也不会排在前几页，也没有展示的机会。. 所以我们添加了一个360-Routing策略来跟进搜索前五页的结果（每页72个产品，一共360个产品）来计算路由，这个路由规则会在接下来的搜索中优先使用。由于前五个页面占流量的 80% 以上，这进一步减少了单次搜索需要访问的分片数量。

　　使用上述Routing规则，在1号店每次搜索的平均索引数据数仅为索引数据的1/3，节省了2/3的资源，提高了搜索效率。

　　自动部署和快速扩展

　　文章一开始我们提到11.11需要搜索系统支持快速扩容。为了明确这个功能，我们首先要从索引部署说起。

　　按类别分片和路由的方式不仅带来了高效率，也带来了管理成本。按类别划分必然会导致每个shard大小不均，相应的路由方案必然会带来每个shard的访问不均。这两个维度的不平衡需要更复杂的索引部署方案。主要原则是：

　　（1）首先根据流量比例和高可用需求确定每个shard的副本数。

　　(2） 那么根据单个节点不能放置同一个 Shard 的多个副本，节点上的流量总和与节点的服务能力成正比。

　　(3） 每个节点上的总索引大小也尽可能保持在最小。

　　根据流量比例计算副本数如下：

　　Shard Replica 备注 S0 4 S1 2 High Availability Constraints S2 4 S3 3 部署后的效果如下图所示。

　　

　　分片数量增加后，部署方案的手动计算变得更加复杂，所以我们将部署方案的生成自动化，一个基本的Packing算法就可以完成这项工作。除了初始部署之外，自动化部署工具还可以支持节点的添加、减少和替换。

　　在11.11的场景下，这个自动化部署工具也可以支持快速扩容。基本流程是：

　　(1）Index Server(部署工具接口)计算扩容后的部署计划，写入ZooKeeper。这里的算法和初始部署有些不同，需要保证现有服务器的shard不变越多越好。

　　(2） 每个 Shard Searcher 服务器都会监控 ZooKeeper 上的部署方案。方案更改后，Shard Searcher 会获取新的方案，并与本地方案进行比较来增加或减少它。

　　(3） Shard Searcher从HDFS获取索引数据，与最新的实时更新数据合并，启动索引服务。

　　使用自动扩容工具，在确定11.11个容量规划后，可以快速部署和启动新服务器，减少人工操作可能引入的错误等问题。推广期间，如果需要紧急扩容，也可以在几分钟内提升整个系统的服务能力。

　　实时监控系统

　　

　　11.11 促销期间，每一分钟都有很大的影响。我们需要实时了解在线数据和服务情况，以确保系统处于一致可用的状态。为此，我们建立了搜索监控系统。

　　索引数据方面，从源头验证索引数据准备的方方面面，包括数据的个数、处理过程中的异常、普通搜索中最后生成的索引执行结果的差异等。使用有问题的索引数据在线的。

　　在搜索服务方面，监控系统会定期进行常用搜索，对结果进行比较和排序，当结果明显不同时及时报警。同时，一些商品在大促期间会很快被抢购一空，这些商品如果继续显示在搜索结果中就没有价值了。搜索监控也会及时检测到这些产品，触发索引更新，将产品排到后面。

　　结语

　　每年11.11是系统的阅兵。通过构建分布式搜索引擎，我们实现了基础架构的可扩展性。结合针对业务场景设计的路由规则，保证搜索和自动化工具的高效执行。支持大促所需的自动扩容，配合系统的验证和监控，我们有信心应对更高流量的冲击，确保大促顺利通过。

　　感谢郭磊对本文的策划和审阅。