转载

Algolia通往高可用搜索API的狂暴之路(系列之一)

Algolia 是一家提供托管式搜索API的初创企业。作为一家年轻的企业,其 架构 令人印象深刻:

  • 其高端专用机器托管在世界上13个地区的25个数据中心里
  • 其master-master配置至少会在三台不同的机器上复制他们的搜索引擎
  • 每个月处理超过60亿次查询
  • 每个月接收和处理超过200亿次写操作

Julien Lemoine 是Algolia的联合创始人兼首席技术官。他计划用一个系列的文章,介绍他们如何分15步构建出如此高可用的基础设施。近日,他发表了这个系列的 第一篇文章 ,重点讨论了前三个步骤。

在开始介绍架构之前,Julien比较了云和裸机。对于大多数情况而言,云基础设施都是一个不错的方案。它易于部署,而且本身提供了高可用性。而基于裸机的基础设施需要他们自己构建高可用性。但选择裸机基础设施,他们可以购买性能更好的硬件,而且与所获得的性能相比,价格也算相当便宜了。

接下来,Julien按时间顺序介绍了Algolia架构演进的前三个阶段,时间跨度为2013年3月到8月。

步骤1:2013年3月

这个阶段,他们的搜索服务API内测版本开始运行。基于对产品市场前景的自信,他们在两个不同的地点(加拿大东部和欧洲西部)分别部署了一台机器。每台机器根据地点为不同的用户提供服务。此时,他们百分百关注性能,时钟频率是他们决策时重点考虑的一个因素,因为就同一代CPU而言,时钟频率与搜索引擎的搜索查询速度有直接关系。索引由单独的进程完成,而且优先级较低;而所有的查询都直接在nginx内处理,并且优先级最高,即它可以占用更多的CPU时间,这样可以有效地处理流量峰值。让他们引以为豪的是,其中一个内部测试用户执意用Algolia的服务替换了其当时正在使用的解决方案。

步骤:2013年6月

经过三个月的开发和大量的测试,他们在Beta测试中引入了高可用性,其思想是:用集群取代了单机,集群由三台相同的机器组成,每台机器都完美地复制了所有数据,均可以作为master。也就是说,每台机器都可以接受用户的写操作,每次写操作都会触发一个一致性保证机制。另外,基于前期的测试,他们发现:

  • 32G的内存不够用,单是索引进程有时候就会用掉10G
  • 磁盘空间不够用,为了处理节点失败,机器需要将多个任务保存在磁盘上

由于内存需求增加,他们将机器由Xeon E3系列换成了Xeon E5系列,因为前者只能处理32G内存。而考虑到时钟频率的重要性,他们决定采用Xeon E5 1600系列。至此,他们已经提供了高可用性。

与此同时,他们还测试了多种负载均衡和故障检测方法,发现所有的硬件负载均衡器均让他们几乎不可能使用多个提供商。于是,他们在API客户端中实现了一种基本的重试策略,即在开发的时候确保每个API都能够访问三台不同的机器。

步骤3:2013年8月

他们将API客户端的数量增加到10种, 包括JS、Ruby、Python、PHP、Objective-C、Java、C#、Node.js等。而且,他们尽量避免自动生成代码,人工开发了API客户端。2013年8月,他们在上述两个地点(加拿大东部和欧洲西部)正式推出了其搜索服务API。每个地点一个集群,每个集群包含三台相同的主机。主机换成了E5-2687W,内存加倍(128G),并且使用了更好的SSD。这主要是因为他们观察到,内存不足以缓存所有的用户数据,而SSD成为索引速度的瓶颈。接下来,他们又重点实现了“可用区域(availability zone)”。关于这一点,Julien并未提供细节信息。

在本系列的下一篇文章中,Julien将介绍其API正式推出后前18个月的情况以及所有意料之外的问题,其中包括第一次停机。

感谢徐川对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群 Algolia通往高可用搜索API的狂暴之路(系列之一) )。

正文到此结束
Loading...