Amazon Simple Queue Service (SQS) – 15 年了，仍在提供队列服务！

时光飞逝！ 早在 2006 年，我就写过关于 Amazon Simple Queue Service (SQS) 产品发布的内容，当时丝毫没有意识到 15 年后，这还是我博客的主题，或者说这项服务依旧保持快速发展，同时仍然是众多不同类型 Web 规模应用程序架构的基础。

SQS 的第一个 Beta 测试版是在 2004 年底宣布推出的，当时几乎没有什么声势。尽管自 Beta 测试版以来，我们添加了许多功能，但原始描述（“用于缓冲分布式应用程序组件之间消息的可靠、高度可扩展的托管队列”）仍然适用。我们的客户将 SQS 视为云中无限的缓冲区，并使用 SQS 队列实现应用程序架构功能组件之间的连接。

多年来，尽管内部极为复杂，但我们一直努力保持 SQS 界面的简单易用。为了确保 SQS 的可扩展性、持久性和可靠性，消息存储在一个由每个 AWS 区域中成千上万台服务器组成的队列中。在一个区域内，我们保存每条消息的三个副本，以便在存储节点和可用区之间分发消息。除了这种内置冗余存储之外，SQS 还具有自我修复能力，可以抵御主机故障和网络中断。尽管 SQS 自发布至今已有 15 年，但我们仍在继续改进扩缩和负载管理应用程序，以便您始终可以依靠 SQS 来处理任务关键型工作负载。

SQS 以令人难以置信的规模运行。例如：

Amazon 商品配送 – 2021 年 Prime 会员日期间，SQS 的流量创下了新纪录，达到每秒 4770 万条消息的峰值。

Rapid7 – Amazon 客户 Rapid7 广泛采用了 SQS。Jeff Myers（平台软件架构师）表示：

Amazon SQS 为我们提供了易于使用、高性能和高度可扩展的消息传递服务，不需要进行任何管理。它是我们架构的一个关键组成部分，使我们能够扩展到每天处理 100 亿条消息。

您可以访问 Amazon SQS 主页，了解 NASA、BMW Group、Capital One 和其他 AWS 客户的其他大规模使用案例。

无服务器办时间
今天（6 月 13 日）请务必在 Twitch.tv 加入我们的“Noon PT 无服务器办时间”。有传言说会有蛋糕！

历史回顾
以下是对 SQS 的一些主要里程碑的快速回顾：

2006 年 – 生产发布。每个账户的队列数量和每个队列的项目数量不受限制，每个项目的长度最多 8 KB。即付即用定价基于发送的消息和传输的数据。

2007 年 – 推出更多功能，包括控制可见性超时和访问大约数量的队列消息。

2009 年 – 欧洲的 SQS，以及通过 AddPermission 和 RemovePermission 提供的更多队列访问控制功能。此次发布还标志着我们当时称之为“访问策略语言”的首次亮相，该语言已发展成为今天的 IAM 政策。

2010 年 – 新的免费套餐（当时每月 10 万个请求，此后扩大到每月 100 万个请求）、可配置的最大消息长度（最多 64 KB）和可配置的消息保留时间。

2011 年 – 每个 SQS 队列增添了更多 CloudWatch 指标。那年晚些时候，我们添加了批处理操作（SendMessageBatch 和 DeleteMessageBatch）、延迟队列和消息计时器。

2012 年 – 支持长轮询，以及对请求批处理和客户端缓冲的开发工具包支持。

2013 年 – 支持更大的负载 (256 KB) 和价格降低 50％。

2014 年 – 支持死信队列，以接受由于超时或代码中的处理错误而卡住的消息。

2015 年 – 使用扩展的客户端库支持扩展的负载（最多 2 GB）。

2016 年 – 支持 FIFO 队列，只需一次处理和重复数据删除，另一次降低价格。

2017 年 – 支持服务器端加密消息和成本分配标签。

2018 年 – 支持使用 AWS PrivateLink 的 Amazon VPC 终端节点以及调用 Lambda 函数的能力。

2019 年 – 支持创建标签和 X-Ray 追踪。

2020 年 – 支持 1 分钟指标，以实现更精细的队列监控、新的控制台体验、ListQueues 结果分页和 ListDeadLetterSourceQueues 函数。

2021 年 – 分层定价可以随着使用量的增加节省资金，以及推出了 FIFO 队列的高吞吐量模式。

如今，SQS 仍然保持简单、可扩展、经济高效且高度可靠。

来自 AWS 勇士
我们请一些 AWS 勇士思考 SQS 的成功之处，并分享他们的一些成功案例。以下是我们了解到的内容：

Eric Hammond（无服务器勇士）使用 AWS Lambda 死信队列。他们在队列上发出告警，并在需要调查问题时发送内部电子邮件作为提示。

Tom McLaughlin（无服务器勇士）自 2015 年以来一直在使用 SQS。他说：“我最喜欢的用例是任何时候有人想要队列，而我不想管理队列平台。永远是这样。”

Ken Collins（无服务器勇士）不完全确定他使用 SQS 具体有多长时间了，只是说使用时间在 2 年至 8 年之间！ 他使用 SQS 为 Lambdakiq 这一重要资源提供支持，后者可在 SQS 和 Lambda 上实施 ActiveJob。

Kyuhyun Byun（无服务器勇士）一直在使用 SQS 来为必须维持大量流量的推送系统提供动力，并告诉我们“十分感谢 SQS，使我不用再为构建队列系统烦心”。

Prashanth HN（无服务器勇士）自 2017 年以来一直在使用 SQS，并认为自己“来晚了”。 他使用 SQS 作为第一个无服务器应用程序的一部分，发现 SQS 非常适合连接具有不同吞吐量的服务。

Ben Kehoe（无服务器勇士）告诉我们：“我第一次看到 SQS 的强大之处是，一位同事向我展示了如何在一组 EC2 Spot 实例中保留状态，方法是在实例关闭时将状态存储在 SQS 中，并让新实例在启动时检查队列中的状态。”

Jeremy Daly（无服务器勇士）于 2010 年开始使用 SQS 作为轻量级队列，为用户提供的图像提供了面部识别过程。今天，他经常使用 SQS 作为缓冲区来限制对尚未无服务器的下游服务的请求。

Casey Lee（容器勇士）也于 2010 年开始使用 SQS 来替代松散耦合的 Java 服务之间的 ActiveMQ。Casey 基于队列深度实施弹性伸缩，并发现这是处理负载的准确方法。

Vlad Ionecsu（容器勇士）早在 2014 年就借助 SQS 开始了他的 AWS 之旅。Vlad 发现 API 非常容易理解，并使用 SQS 为他的论文项目提供支持。

Sheen Brisals（无服务器勇士）于 2018 年开始使用 SQS，当时是在构建一个也使用 Lambda 和 S3 的概念验证。Sheen 非常赞赏能够调整每个队列的特征，以便为消息处理函数创造良好匹配的能力，还可以同时使用高优先级队列和低优先级队列。

Gojko Adzic（无服务器勇士）于 2013 年开始使用 SQS 作为 MindMup 中出口商的任务派遣工具。这个在线思维导图应用程序允许大量用户进行协作，并且需要对每个文档的更新进行严格的排序。Gojko 使用 FIFO 队列，允许他们并行处理不同文档的消息，每个文档内都按顺序排列。

Sebastian Müller（无服务器勇士）于 2016 年开始使用 SQS，为网站建设系统 jimdo.com 建立通知中心。该中心负责确保客户及时了解事件（订单、支持消息和联系请求）。

Luca Bianchi（无服务器勇士）在 2012 年首次使用 SQS。他分离了在 AWS Elastic Beanstalk 上运行的一对微服务，并为游戏化平台创建了扇出处理系统。如今，他最喜欢的 SQS 使用案例用于存储推理作业，并将它们提供给在 Amazon SageMaker 上运行的工作进程。

Peter Hanssens（无服务器勇士）使用 SQS 来卸载不需要立即处理的任务。几年前，在协助一些数据科学家的同时，他创建了一个事件驱动的批处理系统，该系统使用 Lambda 函数每 5 分钟检查一次队列并启动 EC2 实例以构建模型，同时严格控制运行的实例的最大数量。

自 2013 年左右以来，Serkan Ozal（无服务器勇士）一直在使用 SQS。他专注于异步消息处理，并依靠 SQS 的能力来处理大量事件。他还利用消息可见性功能，以便在必要时可以重新处理消息。

Matthieu Napoli（无服务器勇士）从 EC2 开始使用 SQS 约五年，作为其他队列的替代品。正如他所说：“与 Lambda 结合使用，SQS 提供了开箱即用的巨大并行功能，而无需太多考虑它。此外，内置的故障处理功能使其非常强大。”

正如您所看到的那样，SQS 有许多用例。

SQS 资源
如果您还没有使用 SQS，那么现在是进入队列并开始使用的时候了。以下是一些可帮助您找到适合自己的方法的资源：

• Amazon Simple Queue Service (SQS) 主页和定价页面。
• 教程 – Amazon SQS 入门。
• AWS 架构博客 – SQS 类别。
• 视频：介绍 Amazon SQS FIFO 队列。
• 视频：NodeJS 中的 AWS SQS 到 Lambda 教程。

乐享队列服务！

– Jeff；