优化 Amazon Simple Queue Service（SQS）以提高速度并进行扩展



经过几次公开测试后，我们于 2006 年推出了 Amazon Simple Queue Service（Amazon SQS）。将近二十年后，这项完全托管的服务仍然是微服务、分布式系统和无服务器应用程序的基本构建单元，在高峰时段每秒处理超过 1 亿条消息。

因为总有更好的方法，所以我们会继续寻找各种方法，以提高性能、安全性、内部效率等。当我们确实找到了做得更好的潜在方法时，我们会谨慎地保留现有行为，并经常并行运行新旧系统，以比较结果。

今天，我想告诉您，我们最近是如何对 Amazon SQS 进行改进的，以减少延迟、增加实例集容量、缓解即将到来的可扩展性的断崖式变化，并降低功耗。

改进 SQS
与许多 AWS 服务一样，Amazon SQS 是使用一系列内部微服务实现的。今天让我们重点关注其中的两个：

客户前端 – 面向客户的前端接受 CreateQueue 和 SendMessage 等 API 调用，并对其进行验证和授权。然后，它将每个请求路由到存储后端。

存储后端 – 此内部微服务负责持久保存发送到标准（非 FIFO）队列的消息。使用基于单元的模型，单元中的每个集群包含多个主机，为每个客户队列分配一个或多个集群，每个集群负责多个队列：

连接 – 新连接和旧连接
最初的实施在这两个服务之间使用了每个请求的连接。每个前端都必须连接到多台主机，这就要求使用连接池，且有可能达到开放连接数量的最大硬接线限制。尽管通常可以简单地将硬件用于解决此类问题并进行横向扩展，但这并不总是最好的方法。它只是将关键时刻（“可扩展性的断崖式变化”）推向未来，而没有有效地利用资源。

在谨慎考虑了几种长期解决方案之后，Amazon SQS 团队在客户前端和存储后端之间发明了一种新的专有二进制成帧协议。该协议通过单个连接多路传输多个请求和响应，使用 128 位 ID 以及校验和来防止串扰。服务器端加密提供额外的保护层，防止未经授权地访问队列数据。

成功了！
新协议已于今年早些时候投入了使用，在我撰写本文时已经处理了 744.9 万亿个请求。可扩展性的断崖式变化已经消除，我们已经在寻找各种方法，让此新协议以其他方式发挥作用。

在性能方面，新协议将数据平面延迟平均减少了 11％，在 P90 标记时降低了 17.4％。除了提高 SQS 本身的性能外，这一变化还使构建在 SQS 上的服务受益。例如，现在，对于通过 Amazon Simple Notification Service（Amazon SNS）发送的消息，其传送前“内部”时间减少了 10％。最后，由于协议的变化，现有的 SQS 主机实例集（由 X86 和 Graviton 驱动的实例的混合体）现在可以处理的请求比以前多 17.8%。

更多功能即将推出
我希望您喜欢本文对 Amazon SQS 实施的简要介绍。请在评论中告诉我，我会看看能否找到更多故事来分享。

– Jeff；