写点什么

1 号店 11.11:分布式搜索引擎的架构实践

  • 2015-11-11
  • 本文字数:3891 字

    阅读完需:约 13 分钟

“11.11”是一年一度的电商盛宴,为了准备这个一年内最大规模的促销,1 号店各条战线都在紧张有序地忙碌着。1 号店搜索团队经过几年的大促历练,不断推动架构演进,积累了越来越多的经验。

另,ArchSummit 全球架构师峰会北京站将于 2015 年 12 月 18 日~19 日在北京国际会议中心召开,大会设置了《揭秘双十一背后的技术较量》专题来深入解读双十一背后的技术故事,欢迎关注。

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 号店有很多的类目,每个类目的业务模式也不尽相同。以图书和快消品为例,图书是一种典型的长尾商品,它需要索引大量的 SKU(Stock Keeping Unit,可以理解为一个独立的商品),但每个 SKU 的访问量和销量都不高;快消品是另外一个极端,总体 SKU 数量不高,但是访问量和效率都很高。这就造成了一个不平衡的局面,图书的 SKU 数目占比达到了 50% 以上,流量却小于 10%,我们就首先排除了按 Shard 数目取模 (id mod N) 这种平衡划分的策略。

1 号店搜索有两个主要入口,一个是搜索框的搜词,另外是类目导航。在这两个入口中,类目的点击肯定是访问到一个特定的一级类目下,搜词时用户其实也只会关注相关的几个类目。基于这种访问模式,我们就采用了按照类目来切分 Shard 的策略。基本操作为:

(1) 按照一级类目切分 Shard。

(2) 如果该 Shard 过大,则按照二级类目继续切分。

(3) 经过前两步之后,如果切分后的 Shard 过小,则按照相关性进行 Shard 合并。

经过这样一番尝试,Sharding 策略就确定下来,切分之后的 Shard 索引大小一般为 200~500MB,Shard 上单次搜索可以控制在 10ms 以下。

接下来说到 Routing,我们还是分搜词和类目导航两种场景,对于类目导航,原理上非常简单,按照类目 ID 来查找 Sharding 策略,就可以确定需要访问的 Shard,虽然现实中还需要考虑扩展类目等特殊场景,但是也不难做出一个简单的 Routing 策略。再加上类目数是有限的,Routing 规则在 Broker 本地内存就可以缓存起来。

搜词场景就复杂很多,仅凭词本身很难判断它属于哪个 Shard。我们首先按照词的热度分为两类,采取不同的 Routing 策略。对于热词,搜词流量同样符合 80-20 规则,20% 的热词占比 80% 的搜索流量,对于热词,我们可以在建完索引之后,就跑一遍热词搜索,记录那些 Shard 有结果,离线构建出热词 Routing 表。切换索引时,Routing 表也一起加载进去。对于非热词,则采用首次搜索去访问所有 Shard,根据结果记录 Routing 表,这个词在下次搜索时,就有了缓存可用。

基本的 Routing 策略上线之后,通过监控每个 Shard 的访问量,我们又发现了新的问题,图书类目的访问量比它应有的流量要高出不少。仔细分析之后发现,由于图书类目的特殊性,很多词都可以在图书中找到结果,然而这些结果一般都不是用户想要的,实际上也不会排到前几页,并没有展示的机会。于是我们又增加了一种 360-Routing 策略,跟进搜索前五页的结果 (每页 72 个商品,共 360 个商品) 计算 Routing,下次搜索时优先是用这份 Routing 规则。由于前五页的流量占比在 80% 以上,这就进一步减少了单次搜索需要访问的 Shard 数。

使用了以上这些 Routing 规则,1 号店主站搜索每次搜索平均只需要访问 1/3 的索引数据,这就节约了 2/3 的资源,提高了搜索效率。

自动部署与快速扩容

文章一开始我们提到 11.11 要求搜索系统支持快速扩容,为了讲清楚这个功能,我们首先要从索引部署讲起。

按照类目进行 Sharding 和 Routing 的方式,在带来高效的同时,也带来了管理上的成本。按照类目切分,必然会导致各个 Shard 的大小不平均,而对应的 Routing 方案,必然会带来各个 Shard 的访问量不平均。这两个维度不平均就要求更加复杂的索引部署方案,主要的原则为:

(1) 首先根据流量比例和高可用的需求,确定每个 Shard 的副本数。

(2) 然后按照单个节点不能放置同一 Shard 的多个副本,节点上的承担的流量总和与节点的服务能力成正比。

(3) 每个节点上的索引总大小尽量也保持差异最小。

按照流量比例,副本数计算如下:

Shard 副本数 备注 S0 4 S1 2 高可用约束 S2 4 S3 3 部署之后的效果如下图所示。

Shard 数增多之后,人工计算部署方案就显得较为复杂,于是我们就把部署方案生成做成了自动化,一个基本的 Packing 算法就可以完成这个工作。除了初始部署之外,自动部署工具还可以支持节点增加、减少和更换。

在 11.11 的场景下,这个自动化部署工具也可以支持快速扩容,基本过程为:

(1) Index Server(部署工具界面)计算出扩容之后的部署方案,写入到 ZooKeeper。这里的算法与初始部署有些不同,它需要保证现有服务器的 Shard 尽量不变。

(2) 每个 Shard Searcher 服务器都会监听 ZooKeeper 上的部署方案,方案改变之后,Shard Searcher 会获取新的方案与本地方案对比,进行增减操作。

(3) Shard Searcher 从 HDFS 上获取索引数据,与最近的实时更新数据合并之后,启动索引提供服务。

有了自动扩容工具,11.11 容量规划确定之后,新的服务器就可以很快部署上线,也减少了人工操作可能引入的失误等问题。大促期间如果需要紧急扩容,也可以在几分钟内提高整个系统的服务能力。

实时监控体系

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

在索引数据方面,从源头开始对索引数据准备的各个环节进行验证,包括数据的条数、处理过程中的异常、最后生成的索引在常见搜索中的执行结果差异等,层层预防,防止有问题的索引数据被用到线上。

在搜索服务方面,监控系统会定时执行常见的搜索,对比排序结果,结果差异较大时及时告警。同时大促期间会有一些商品很快卖完,这些商品继续显示在搜索结果中也没有价值,搜索监控也会及时发现这些商品,触发索引更新,把商品排到后面。

结语

每年 11.11 对系统都是一次大阅兵,通过构建分布式搜索引擎,我们实现了基础架构的可扩展性,结合业务场景设计的 Routing 规则,保证了搜索的高效执行,自动化工具支持大促必需的自动扩容,配合成体系的验证和监控,我们有信心应对更高流量的冲击,保障大促平稳度过。


感谢郭蕾对本文的策划和审校。

2015-11-11 17:147573

评论

发布
暂无评论
发现更多内容

扎根CNCF社区贡献五年是怎样的体验?听听华为云原生开源团队的负责人怎么说

华为云开发者联盟

容器 Volcano cncf kubeedge 代码开发

个人web分享92道JavaScript面试题附加回答

我是哪吒

程序员 面试 大前端 程序媛

2021最新Windows10环境下安装MacOS系统(黑苹果)亲测有效!!(VM安装黑苹果)

Z.

macos 黑苹果 windows vmware

幕后故事 | YRCloudFile助力顶级视效制作公司MORE VFX打造视觉盛宴

焱融科技

高性能 存储 焱融科技 3D渲染 影视制作

Java 读写锁 原来这么简单

Java架构师迁哥

15道类和对象面试题,快看看自己会几道

田维常

类集

顺利拿到OPPO公司Android架构师offer,Android跨进程通信导论,全套教学资料

欢喜学安卓

android 程序员 面试 移动开发

Invalid bound statement (not found)

任广印

Java MyBatisPlus

Appium下的WDA使用个人开发者证书配置

行者AI

自动化测试

12.4G阿里巴巴面经公开:技术笔记+视频讲解+简历模板,绝了!

996小迁

Java 架构 面试 程序人生

数字货币写进多地“十四五”规划纲要草案 专家建议扩大数字人民币试点范围

CECBC

数字经济

音视频传输协议众多, 5G时代不同业务应该如何选择?

华为云开发者联盟

5G 音视频 直播 流媒体

一文带你解读Volcano架构设计与原理

华为云开发者联盟

架构 Kubernetes 负载 Volcano 集群

666666666666666666666

Paul

大数据

Kubernetes生产环境最佳实践

xcbeyond

Kubernetes 容器 28天写作

区块链有望被主流接纳的四个场景

CECBC

区块链

硬核!我花5小时肝出这篇Redis缓存解决方案,带你起飞!

数据库 redis 缓存架构

每日知识总结

country

5G机遇 | 如何解决在核心场景的高并发、超低延迟需求?

VoltDB

数据库 5G 通信 VoltDB

为什么强烈推荐 Java 程序员使用 Google Guava 编程!

沉默王二

Java Guava

企业项目迁移go-zero全攻略(二)

万俊峰Kevin

微服务 microservice Go 语言

重温亮剑-感悟

superman

技术赋能教育,浅谈教育机构转型的制胜关键

华为云开发者联盟

音视频 在线教育

宅米网技术架构演进分析

Andy

java中的类和object,其实没那么难~

田维常

类集

太牛了!美团Android开发工程师岗位职能要求,大厂面试题汇总

欢喜学安卓

android 程序员 面试 移动开发

从设计模式理解Vue响应式(多图警告)

coolFish(呔呆)

JavaScript vue.js 响应式 大前端 设计模式

区块链如何帮助联合国支持全球教育?

CECBC

区块链

认识Nacos注册中心

登风

nacos

工具介绍 | 百度开源Server-Agent:高性能、高效率的任务调度执行引擎

百度开发者中心

开源

怎么理解Kafka消费者与消费组之间的关系?

码农架构

Java 架构 消息队列 消息中间件

1号店11.11:分布式搜索引擎的架构实践_语言 & 开发_周航_InfoQ精选文章