写点什么

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

  • 2015-07-30
  • 本文字数:2194 字

    阅读完需:约 7 分钟

在本系列的第一第二篇文章中,Algolia 联合创始人兼首席技术官Julien Lemoine 分别介绍了他们构建高可用基础设施的前3 个步骤和自2013 年9 月API 正式推出至2014 年12 月18 个月间的情况以及所有意料之外的问题(其中包括第一次停机)。近日,本系列的第三篇文章发表,主要介绍他们如何从一个“初创企业”的架构转变成一个可以满足大型上市公司需求的架构。

步骤11:2015 年2 月——全球同步的基础设施

这个月,他们实现了自2014 年4 月开始就一直为之努力的目标,“将服务扩展到全球,更好地服务于用户”。他们的网络包含12 个不同的地点:美国东部(弗吉尼亚)、美国西部(加利福尼亚)、澳大利亚、巴西、加拿大、法国、德国、香港、印度、日本、俄罗斯和新加坡。最重要的是,他们推出了“分布式搜索”特性。借助这个特性,用户只需几次点击就可以在他们的网络中选定需要自动复制数据的地点。用户使用的API 保持不变,而查询请求会自动路由到最近的地点。这不仅降低了延迟,还提高了搜索基础设施的可用性。

据Julien 介绍,他们的“分布式搜索网络(Distributed Search Network,DSN)”与CDN(内容分发网络)完全不同。他们不是在每个边缘地点缓存常用查询,而是存储一个包含所有数据的完整副本。边缘地点本身都可以响应任何查询。就是说,如果用户选择了三个接入点(美国东部、德国、新加坡),那么位于德国的接入点会响应欧洲用户的查询,位于新加坡的接入点会响应亚洲用户的查询,而位于美国东部的接入点则会响应美国用户的查询。

为了支持这种变化,他们修改了API 客户端的重试逻辑。客户端会首先指向主机名 APPID-dsn.algolia.net ,后者会使用 DNS 将客户端请求路由到最近的地点。如果最近的主机不可用,那么为了能够返回下一个最近的地点,DNS 记录会在 1 分钟内删除那台主机。这就是他们将每条记录的 TTL 设为 1 分钟的原因。如果遇到这种故障,那么他们的官方 API 客户端会通过在 APPID-1.algolia.net APPID-2.algolia.net APPID-3.algolia.net 上重试将流量重定向到“主区域(main region)”。他们认为,这种方法可以实现高性能与高可用性的最佳平衡。

步骤 12:2015 年 3 月——提高单个地点的高可用性

对于搜索和国际用户而言,分布式搜索网络极大的提高了可用性。而为了提高主区域的可用性,他们将美国的集群分布在两个完全独立的提供商那里:

  • 两个位置相近的、不同的数据中心;
  • 三台不同的机器——同以前一样,两台位于一个数据中心的不同的可用区域中,一台位于另一个数据中心;
  • 两个不同的自治系统。

这样,他们可以选择将流量路由到另一个提供商。他们在提高单个地点的可用性方面迈进了很大一步。

步骤 13:2015 年 4 月——随机出现的文件损坏问题

这个月,他们开始注意到生产环境中随机出现的文件损坏问题,这是由部分 SSD 的 TRIM 实现中存在 Bug 导致的(具体原因参见这里)。这是个棘手的问题,他们花了一个月的时间来跟踪和定位。所幸,他们没有丢失任何客户数据,这主要得益于以下两个方面:

  • 他们存储了数据的三个副本;
  • 更重要的是,他们没有复制索引操作的结果,而是在每台机器上重复了用户的操作。这有效避免了问题向其它机器传播。

他们没有预见到这种问题,但使用独立的机器是他们能够将问题影响最小化的原因。因此,Julien 强烈建议,任何需要高可用性的系统都要采用这种独立性。

步骤 14:2015 年 5 月——引入多个 DNS 提供商

他们选择 NSONE 作为一个 DNS 提供商,因为该提供商提供了很棒的 DNS API,允许他们通过 API 针对每个用户配置查询的路由方式,并且支持 edns-client-subnets ,可以提供更准确的地理位置路由。

这里的挑战在于,他们需要引入第二家 DNS 提供商,而又不损失 NSONE 提供的强大功能。他们决定通过修改 API 客户端重试策略的方式引入。所有的 API 客户端都会首先连接 APPID-dsn.algolia.net ,如果有问题,它们会在另一个提供商提供的顶级域名上重试。他们选择将 AWS Route 53 作为第二家提供商。如果有任何问题,API 客户端将从 APPID-1.algolianet.com APPID-2.algolianet.com APPID-3.algolianet.com 中随机选择一个重试。这样,他们就在 algolia.net 域上保留了 NSONE 所有的地理位置路由特性,同时引入了第二个提供商在 algolianet.com 域上提供了更高的可用性。

步骤 15:2015 年 7 月——每个集群跨三个完全独立的提供商

虽然经过了一系列的扩展,但他们的基础设施并不能完全应对所有问题,这主要是因为 Link/Router 丢失数据包和路由泄露。在上个步骤中,他们改进了在美国的部署,构建了跨多个数据中心、多个自治系统和多个上游提供商的集群。不过,索引操作需要三台机器中的两台运行正常方可进行。当使用两个提供商时,如果其中一个宕掉,他们就会无法提供索引服务,但搜索服务仍然可用。正是因为这个原因,他们决定实现跨三个完全独立的提供商的集群。这让他们的基础设施超级冗余,但却同时提供了高可用的搜索和索引服务。

总之,构建高可用的架构是需要时间的。所以,作为初创企业,不用在开始的时候就担心基础设施不够完美。但是,应该尽早考虑如何扩展基础设施,Julien 甚至建议在 Beta 测试之前就开始。


感谢徐川对本文的审校。

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

2015-07-30 08:221890
用户头像

发布了 1008 篇内容, 共 422.3 次阅读, 收获喜欢 346 次。

关注

评论

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

经典gba游戏(寂静岭、节奏天国、机兽新世纪等)游戏合集

Rose

DeepSeek与Web3:科技融合的新纪元

TechubNews

AI DeepSeek 深度探索

主动元数据对金融机构监管报送有何帮助?

Aloudata

元数据 全链路数据血缘 数据血缘 主动元数据

国内服务器配置Docker国内源-极限加速

知识浅谈

Docker Linux Docker 镜像

浙江AI最强阵容出炉,中之杰智能跻身前列

财见

汉化直装版 Navicat for MySQL 数据库 for Mac/win 安装包

Rose

WebGIS项目的测试

北京木奇移动技术有限公司

软件外包公司 webGIS开发 GIS开发

iStat Menus for Mac:全面监控,轻松掌握系统状态

Rose

合合信息启信宝助力国家自然科学基金委员会重点专项推进

合合技术团队

人工智能 技术 大模型

银行SRE转型:如何突破传统运维困境,打造高效团队

嘉为蓝鲸

运维 SRE SRE团队

CleverTap获得最新Gartner®个性化引擎Magic Quadrant™认证

财见

突破数据壁垒,动态住宅代理IP在数据采集中的高效应用

dvlinker

数据采集

原理剖析:一文搞懂 Kafka Producer(下)

AutoMQ

云计算 大数据 数据流 Kafka Producer

Keka for Mac(mac压缩解压软件)v1.3.6中文版

Rose

前端 TypeError 错误永久消失术

vivo互联网技术

前端 web前端 babel

SRE转型:不同团队规模下的银行SRE团队组建策略

嘉为蓝鲸

运维 SRE 运维团队 运维转型

SRE转型:银行 SRE 转型与 SLO 管理的深度融合

嘉为蓝鲸

SRE IT 运维

得物端智能视频封面推荐

得物技术

前端

音乐NFT系统的上线

北京木奇移动技术有限公司

NFT数字藏品系统 软件外包公司 音乐NFT

受需求增长推动,美国制造业一月份回升

财见

【榜单解析】2025年数据安全性超强的10款项目管理软件,你选对了吗?

薛同学

高级文本编辑器UltraEdit 中文汉化破解版-Mac/win

Rose

CCleaner pro for mac/win(全能型系统优化软件) 汉化免激活版

Rose

Macs Fan Control Pro for mac( 电脑风扇控制软件)v1.5.16中文激活版

Rose

免费体验!一键部署DeepSeek!

九章云极DataCanvas

DeepSeek

工信部批准《研运流程数字化平台成熟度模型》行标发布

嘉为蓝鲸

工信部 研发运维 研运流程数字化

大人,时代变了! 赶快把自有业务的本地AI“模型”训练起来!

不在线第一只蜗牛

人工智能 AI

Algolia通往高可用搜索API的狂暴之路(系列之三)_架构_谢丽_InfoQ精选文章