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 读者交流群）。