Amazon SQS 入门：从基础到进阶的完整指南

这是对Amazon Simple Queue Service (Amazon SQS)的历史年表的介绍。Amazon SQS作为AWS的基础设施服务之一，于2004年11月首次推出，提供全托管的消息排队服务。为了迎接即将到来的2024年11月的20周年，我们提前撰写了这篇文章，以纪念这一里程碑。文章总结了SQS从诞生至今的主要功能和更新内容，希望能够帮助读者了解AWS服务的功能概述、核心概念以及其发展的历程。

Amazon SQS历史年表的制作背景与方法

这次制作Amazon SQS历史年表的动机是为了纪念2024年即将到来的20周年。Amazon SQS于2004年11月作为AWS的第一个基础设施服务发布（注1）。2024年也因此成为AWS基础设施服务发布20周年的重要年份。

此外，自2004年11月作为第一个AWS基础设施服务推出以来，Amazon SQS一直提供全托管的消息队列服务，即使在IT趋势变化的过程中，如分布式系统、微服务、无服务器应用程序等领域，它仍然广泛使用。为了更好地整理Amazon SQS的信息，我采用了以下方法：

1. 回顾Amazon SQS的历史，整理其更新演变过程。
2. 汇总Amazon SQS的功能列表及特点。

这个年表主要参考了以下博客和文档历史中关于Amazon SQS的内容：

• What's New with AWS?
• AWS News Blog
• Documentation history - Amazon Simple Queue Service

由于参考资料的发布时间不同，年表中的日期可能存在一定的误差。所展示的内容仅限于当前与Amazon SQS相关的主要功能和概要说明，并非涵盖所有的更新。请注意，年表中的内容是我选取的代表性更新，而不是全部的功能更新。

注1) 参见“Introducing the Amazon Simple Queue Service”。在基础设施服务之外，还有名为“Alexa Web Information Service (AWIS)”的服务，在Amazon SQS之前于2004年10月4日记录在“What's New | 2004”中。而最早实现一般可用性（GA）的服务是Amazon Simple Storage Service (Amazon S3)，在2006年3月14日宣布并上线。

Amazon SQS历史年表（2004年11月3日～2024年5月1日的更新）

接下来是关于Amazon SQS功能的历史年表。截至本文撰写时，Amazon SQS已有19年6个月的历史，并将在2024年11月迎来20周年。

年月日	概要
2004/11/03	Amazon Simple Queue Service (Amazon SQS) 发布。
2006/07/11	Amazon Simple Queue Service (Amazon SQS) 正式发布 (GA)。
2011/10/06	AWS 管理控制台中添加了 Amazon SQS 支持。
2011/10/21	支持延迟队列、消息计时器和批处理 API。
2012/11/05	Amazon SQS API 版本 2012 年 11 月 5 日发布。
2012/11/08	支持长轮询。
2012/11/21	您现在可以使用适用于 Amazon SQS 的 AWS 管理控制台为 Amazon SQS 队列订阅 Amazon SNS 主题。
2013/06/18	允许的最大有效负载大小从 64KB 增加到 256KB。
2014/01/29	支持死信队列。
2014/05/06	支持消息属性。
2014/07/16	您现在可以使用 AWS CloudTrail 记录 Amazon SQS API 操作。
2014/12/08	现在可以使用 PurgeQueue API 操作删除队列中的消息。
2014/12/29	适用于 JMS 的 Amazon SQS Java 消息传递库现已推出。
2015/10/27	适用于 Java 的 Amazon SQS 扩展客户端库现已推出，允许您使用 Amazon S3 发送和接收负载高达 2GB 的消息。
2016/03/30	Amazon CloudWatch Events 服务现在支持 Amazon SQS 队列作为事件目标。
2016/08/31	您现在可以使用 ApproximateAgeOfOldestMessage CloudWatch 指标监控队列中最旧消息的期限。
2016/11/17	FIFO（先进先出）队列现已可用，现有队列的新名称是标准队列。
2017/04/24	Amazon SQS Extended Client Library for Java 和 Amazon SQS Java Messaging Library for JMS 已经开始支持 FIFO 队列。
2017/04/28	支持服务器端加密（SSE）。
2017/05/01	Amazon SQS 成为符合 HIPAA 要求的服务。
2017/05/19	您现在可以将适用于 Java 的 Amazon SQS 扩展客户端库与适用于 JMS 的 Amazon SQS Java 消息传递库结合使用。
2017/10/19	标签现在可用于 Amazon SQS 队列，允许您使用成本分配标签跟踪成本分配。
2017/12/07	除 ListQueues 之外的所有 API 操作都支持资源级权限。
2018/04/10	Amazon CloudWatch Events 服务现在支持 Amazon SQS FIFO 队列作为事件目标。
2018/06/28	AWS Lambda 现在支持 Amazon SQS 标准队列作为事件源。
2018/12/13	支持使用 AWS PrivateLink 的 Amazon VPC 终端节点，允许您私下连接到支持 VPC 的 AWS 服务。
2019/04/04	支持VPC端点策略。
2019/07/25	临时队列客户端变得可用。
2019/08/22	支持Tag-on-create，在创建队列时进行标记。您现在可以指定 AWS IAM“aws:TagKeys”密钥和“aws:RequestTag”密钥。
2019/08/28	支持使用 AWS X-Ray 对队列进行故障排除。
2019/11/19	AWS Lambda 现在支持 Amazon SQS FIFO 队列作为事件源。
2019/12/11	1 分钟 Amazon CloudWatch 指标现已推出。
2020/06/22	ListQueues 和 ListDeadLetterSourceQueues API 现在支持分页，允许您指定从请求返回的最大结果数。
2020/12/17	预览 FIFO 队列中消息的高吞吐量模式的发布。
2021/05/27	FIFO 队列中的高吞吐量模式变为 GA（通用可用性）。
2021/11/23	使用 Amazon SQS 托管加密密钥的服务器端加密 (SSE-SQS) 现已推出。
2021/12/01	标准提示现在支持死信提示的重新驱动。
2022/10/04	支持使用 Amazon SQS 托管加密密钥默认启用服务器端加密 (SSE-SQS)。
2022/11/17	引入基于属性的访问控制（ABAC）。 。
2023/07/27	Amazon SQS 现在提供使用 AWS JSON 协议的 API 请求的预览版。
2023/11/27	FIFO 队列现在支持死信队列重新驱动。
2024/02/06	适用于 Python 的 Amazon SQS 扩展客户端库现已推出，允许您使用 Amazon S3 发送和接收负载高达 2GB 的消息。

现有的Amazon SQS功能列表及概述

在这里，我们将详细介绍当前Amazon SQS的主要功能。

Amazon Simple Queue Service（Amazon SQS）是一种高度可靠和可扩展的全托管消息排队服务，用于在微服务、分布式系统和无服务器应用程序之间进行消息交换。通过提供高可靠性和持久性的消息队列服务，Amazon SQS使得应用程序之间的异步处理和高效的消息交换成为可能。

此外，自动扩展和数据冗余性使得系统能够适应负载变化，并防止消息丢失。按使用量计费的定价模式提供了具有成本效益的解决方案，同时，通过AWS Identity and Access Management（IAM）进行访问管理，以及在传输和存储过程中对数据进行加密，从而实现高安全性。

这些特点使得Amazon SQS可以轻松集成其他AWS服务，快速开发应用程序并实现灵活的操作。

Amazon SQS的使用场景

Amazon SQS被设计用于增强系统的容错性和扩展性，适用于多种场景。以下是一些主要的使用场景：

• 异步通信：允许应用程序之间异步传输消息，使系统组件独立并可扩展处理。
• 负载均衡：在高峰期或突发流量时，通过保留消息在队列中防止后续系统过载。
• 分布式系统集成：在分布式架构中的不同系统组件之间交换消息。

使用实例

1. 电子商务订单系统：订单信息通过SQS传递到订单处理服务，确保在高负载时订单数据不丢失。
2. 微服务间通信：在微服务架构中使用SQS实现服务之间的松耦合，增强系统的恢复力。
3. 大数据应用：通过SQS从数据收集点收集数据，用于批处理或流处理。

这些使用场景展示了Amazon SQS在不同业务需求下提供的灵活性和可靠性。

Amazon SQS的概念图

在介绍Amazon SQS的主要功能和特点之前，下面提供了Amazon SQS的概念图，帮助您更容易理解其整体结构和功能。

Amazon SQS 提供操作基本队列的操作。
负责向 Amazon SQS 队列发送消息的系统称为生产者，负责从 Amazon SQS 队列接收和删除消息的系统称为使用者。
上面的概念图​​假设生产者和消费者是使用 AWS Lambda Functions 实现的。

生产者使用SendMessage将消息发送到 Amazon SQS 队列，使用者使用ReceiveMessage从 Amazon SQS 队列接收消息，并在处理完消息后使用DeleteMessage删除该消息。
除了概念图中描述的 API 操作（如SendMessage 、 ReceiveMessage和DeleteMessage之外，还有批处理 API 操作（如SendMessageBatch 、 ReceiveMessage和DeleteMessageBatch 。

Amazon SQS 标准队列是一种可以以近乎无限的吞吐量处理消息的队列类型，但不保证消息顺序并且存在重复的消息传递。
另一方面，Amazon SQS FIFO 队列是一种吞吐量有限但保证消息排序和一次性消息传送的队列类型。
下面，我们将解释 Amazon SQS 标准队列和 Amazon SQS FIFO 队列。

Amazon SQS 标准队列

Amazon SQS 标准队列是一项强大的托管消息队列服务，它提供了一种在分布式系统之间异步发送和接收消息的机制。
主要标准球杆功能包括：

•  交易次数无限制
  标准队列支持无限数量的事务，并且对 API 操作（例如SendMessage 、 ReceiveMessage和DeleteMessage ）的调用数量没有上限。这适用于需要高处理能力或吞吐量的应用。

• “至少一次交付”
  标准队列保证消息至少传递一次。但是，需要注意的是，标准队列可以允许多次传递消息。

•  尽力保存订单
  标准队列通常按照发送消息的顺序接收消息。但是，标准队列并不能保证消息的严格排序，并且在极少数情况下顺序可能会发生变化，因此如果需要完整排序，建议使用 FIFO 队列。

因此，标准队列可以有效地用于需要持久且可扩展的消息传递解决方案的各种应用程序中。然而，假设应用程序可以处理消息传递的重叠和排序。

Amazon SQS FIFO 队列

Amazon SQS FIFO 队列（FIFO 队列）是一种适用于特定使用案例的队列服务，它提供严格的消息排序并能够消除重复消息。
FIFO 队列具有顺序保留功能，可确保按照发送消息的顺序从队列中检索消息，并且具有重复数据删除功能，可保证“一次性传送”。

 消息严格排序（保序功能）

先进先出队列严格维护消息发送的顺序。消息按照先进先出的原则进行处理，同一消息组内的消息顺序不会改变。

 Exactly Once处理（去重功能）

FIFO 队列与标准队列的不同之处在于它们最大限度地减少了重复消息。 FIFO队列默认有5分钟的重复数据删除窗口，即使在这段时间内再次发送具有相同消息重复数据删除ID的消息，也只会将其添加到队列中一次。重复数据删除有两种方法：

• 自动生成消息去重ID
  启用基于内容的重复数据删除后，Amazon SQS 使用 SHA-256 哈希从消息内容自动生成唯一的消息重复数据删除 ID。该ID是根据消息正文的内容生成的，不考虑消息属性。

• 指定显式消息重复数据删除 ID
  开发者在发送消息时可以指定自己的消息去重ID。即使在同一个重复数据删除窗口内发送具有相同 ID 的消息，这些消息也只会被添加到队列中一次。

通过利用这些功能，可以在 FIFO 队列上实现“一次性处理”，确保消息的处理不会重复或丢失。

 从标准队列迁移到 FIFO 队列

如果使用标准队列的现有应用程序需要严格的消息排序以及处理一次性消息的能力，则需要从标准队列到 FIFO 队列的适当转换。此迁移通常用于确保应用程序需要消息排序和重复数据删除。

但是，无法直接将标准队列转换为 FIFO 队列，因此请使用以下步骤之一进行迁移。

• 删除现有的标准队列并创建新的 FIFO 队列
• 只需添加一个新的 FIFO 队列并保持现有标准队列不变

这两种方法都需要对应用程序进行适当的配置更改，以充分利用 FIFO 队列的特性并保持排序和处理的一致性。通过此过程，应用程序可以支持更高级的消息传递需求。

以下是迁移过程的摘要以及从标准队列迁移到 FIFO 队列时要考虑的要点。

 迁移过程

1.  重新创建队列
   标准队列不能直接转换为 FIFO 队列。您必须创建新的 FIFO 队列或删除现有标准队列并将其重新创建为 FIFO 队列。
2.  调整应用程序
   需要更改应用程序代码才能利用特定于 FIFO 队列的功能（消息组 ID、重复数据删除 ID 等）。

 需要考虑的事项

•  使用高吞吐量模式
  您可以通过启用 FIFO 队列的高吞吐量模式来最大化消息发送吞吐量。但该模式有一定的局限性，使用前请先查看AWS文档了解详细信息。
•  设置延迟
  FIFO 队列允许您为整个队列而不是单个消息设置延迟。如果需要为单个消息设置延迟，则必须在应用程序端完成。
•  使用消息组
  通过对相似或相关的任务进行分组，您可以维护消息顺序并在多个处理器上执行并行处理。正确的消息组 ID 设计对于有效扩展非常重要。
•  重复数据删除策略
  使用重复数据删除 ID 可防止同一消息被处理两次。您还可以启用基于内容的重复数据删除。
•  管理可见性超时
  如果您的消息需要很长时间来处理并且您需要延长可见性超时，请考虑向每个 ReceiveMessage 操作添加接收请求尝试 ID 以管理接收尝试重试。

通过适当地进行这些更改，应用程序可以充分利用 FIFO 队列的特性，实现更可靠、更高效的消息处理。

 FIFO 队列的高吞吐量

FIFO 队列的高吞吐量支持增加每个 API 每秒的请求数。
您可以通过启用 FIFO 队列的高吞吐量来增加每个 API 每秒的请求数。
要增加 FIFO 队列中的请求数量，您可以增加使用的消息组数量。

Amazon SQS 将数据存储在分区内的 FIFO 队列中。
分区是为队列分配的存储，这些队列会在 AWS 区域内的多个可用区之间自动复制。
您不管理分区；Amazon SQS 为您进行分区管理。

您可以为新的或现有的 FIFO 队列启用高吞吐量。
创建和编辑 FIFO 队列时提供三个选项：

•  启用高吞吐量 FIFO
  为当前 FIFO 队列中的消息启用更高的吞吐量。
•  重复数据删除的范围
  指定是在整个队列上还是在每个消息组的基础上进行重复数据删除。
•  FIFO 吞吐量限制
  指定是为整个队列还是为每个消息组设置 FIFO 队列中消息的吞吐量限制。

要启用 FIFO 队列的高吞吐量，请在创建或编辑队列时选择启用高吞吐量 FIFO 选项。这将自动配置以下设置：

•  重复数据删除范围设置为消息组
• FIFO 吞吐量限制按消息组 ID 设置

启用高吞吐量 FIFO 模式会自动为每个消息组设置重复数据删除和 FIFO 队列吞吐量限制。
如果需要更改这些自动设置，队列将自动恢复到正常吞吐量模式，但重复数据删除将继续按照用户指定的方式进行处理。

创建或编辑队列后，您可以发送、接收和删除高事务率的消息。
FIFO 队列的高吞吐量允许您每个消息组 ID 每秒发送和接收多达 3,000 条消息。
但是，此限制适用于每个消息组 ID，因此您可以通过增加消息组的数量来增加总体队列吞吐量。

Amazon SQS 标准队列与 Amazon SQS FIFO 队列之间的差异和比较

下表总结了 Amazon SQS 标准队列和 Amazon SQS FIFO 队列之间的差异和比较。

比较项目	Amazon SQS 标准队列	Amazon SQS FIFO 队列
配信保证	至少一次送货。  （也有可能重复分发。）	正好一次交货。
配信顺序	最大努力。  （顺序可能会改变。）	在消息组内保持先进先出的顺序。
吞吐量	几乎无限。	每个 API 操作（SendMessage、ReceiveMessage、DeleteMessage）每秒最多处理 300 个事务。 每个 API 操作（SendMessageBatch、ReceiveMessage、DeleteMessageBatch）每秒最多可批量处理 3,000 条消息。 启用高吞吐量允许您分配更高的吞吐量。

 亚马逊SQS的主要特点

下面，我们将解释 Amazon SQS 标准队列和 FIFO 队列可用的主要功能。

短轮询和长轮询

Amazon SQS 提供两种接收消息的方法：短轮询和长轮询。
短轮询是默认设置，在消息频繁到达的环境中很有用，而长轮询有助于在消息不频繁到达的环境中降低成本并提高效率。

 短轮询

短轮询的工作原理是向队列的子集（随机选择的一组服务器）发出 ReceiveMessage 请求并立即返回可用消息。
即使消息不存在，SQS 也会立即返回响应。
因此，如果队列中的消息数量较少，连续请求可能会检索到消息，但一次请求可能无法检索到所有消息。
重复请求可以让您从队列中均匀地接收消息，但在没有消息时重复请求会产生成本和增加流量的风险。

 长轮询

长轮询会等待 ReceiveMessage 请求设置 ( ReceiveMessageWaitTimeSeconds ) 并查询所有 SQS 服务器。
SQS 会保留响应，直到找到至少一条消息或指定的等待时间已过。
当有新消息到达时，立即响应并等待其他消息，直到达到最大消息数。
如果等待时间结束后没有消息，则返回空响应。
长轮询减少了不必要的请求，减少了虚假的空响应（消息存在但未包含在响应中的情况），并提高了成本效率。
通过将ReceiveMessageWaitTimeSeconds设置为大于 0 的值来启用，允许最长等待 20 秒。
等待期间没有额外的流量，提高了性价比。
当消息不频繁到达或应用程序具有更多处理能力时，这可以实现高效的消息处理。

死信队列

死信队列用于隔离无法处理的消息，对于调试和问题分析很有用。
当消息超过预定的接收尝试次数 ( maxReceiveCount ) 时，此功能会自动将消息移至死信队列。死信队列对于隔离有问题的消息并使其更容易诊断原因非常重要。

死信队列不会自动创建。您需要提前创建一个队列并将其用作死信队列。
另外，对于 FIFO 队列来说，死信队列也必须是 FIFO 队列，同样，对于标准队列来说，它们也必须是标准队列。
死信队列和其他队列必须位于同一 AWS 账户和同一区域。

maxReceiveCount指定消息在移动到死信队列之前从源队列接收的次数。
较低的值意味着消息在较少的接收尝试后会移至死信队列，例如，由于网络错误或客户端相关错误。
但是，必须将maxReceiveCount的值设置为允许有足够的重试机会，以便系统从错误中恢复。

在确定消息处理失败的原因后，或者在消息可供使用后，您可以使用重新驱动策略将消息从死信队列移回其原始源队列。
从死信队列中移动消息时，您需要根据 API 调用次数付费，并根据 Amazon SQS 定价进行计费。

要设置死信队列，首先创建一个用作死信队列的队列。
然后，在源队列配置中，指定用作死信队列的队列并设置maxReceiveCount的值。
这样可以确保处理失败的消息自动移动到指定的死信队列中。

应该使用死信队列的场景是当消息处理失败并且您需要确定问题原因并采取适当的操作时。
例如，与外部服务合作失败或者消息格式不正确。

将消息移出死信队列的方法是使用重新驱动策略。
重新驱动策略是用于将消息从死信队列返回到原始源队列的设置。
通过设置重新驱动策略，您可以重新处理死信队列中积累的消息。

您可以利用 CloudWatch 指标对死信队列进行调试和故障排除。
通过监控死信队列相关指标，您可以了解有多少消息处理失败、有多少消息卡在死信队列中等。
根据这些信息，您可以采取适当的措施。

配置和使用死信队列有许多实现注意事项和最佳实践，需要正确的设计和操作。
示例包括适当调整死信队列的大小以及定期监视滞留在死信队列中的消息。
建议您牢记这几点，谨慎配置和操作。

可见性超时

可见性超时是指阻止其他使用者（接收和处理消息的应用程序）在处理消息时接收消息的一段时间。
Amazon SQS 在此超时期间阻止接收来自其他使用者的消息。
默认可见性超时为 30 秒，但可配置为 0 秒到 12 小时。

正确设置可见性超时很重要。消费者必须在此期限内完成消息的处理和删除。
如果在处理完成之前超时，消息可能会被其他消费者再次收到。这降低了同一消息被多次处理的风险。

但是，对于标准队列，设置可见性超时并不能完全防止接收重复消息（由于“至少一次传递”策略）。
另一方面，FIFO 队列使用消息重复数据删除 ID 和接收请求尝试 ID 来允许生产者和消费者在必要时重试发送和接收。

 飞行中消息

Amazon SQS 消息具有三种状态。

•  状态从生产者发送到队列
•  消费者从队列接收到的状态
•  从队列中删除

由生产者发送但尚未接收的消息被视为“静止”，并且发送的消息数量没有限制。
另一方面，消费者收到但未删除的消息称为“正在传输”，并且其数量是有限制的。
对于标准队列，传输中消息的最大数量为 120,000 条；对于 FIFO 队列，传输中消息的最大数量为 20,000 条。

您可以更改每个队列的默认可见性超时值或在接收消息时指定特定的超时值。
如果您需要超过 12 小时的处理时间，您可能需要考虑使用 AWS Step Functions。

 可见性超时的最佳实践

如果您不确定消息处理时间，请为消费者进程实现心跳。
例如，将初始可见性超时设置为 2 分钟，只要消费者继续处理，每分钟添加 2 分钟超时。
如果处理开始后发现超时不够，可以通过在ChangeMessageVisibility操作中指定新的超时值来缩短或延长可见性超时。
或者，如果您决定不处理它，您仍然可以在ChangeMessageVisibility操作中将超时设置为 0，从而允许其他组件立即看到该消息以进行重新处理。

 延迟队列

Amazon SQS 的延迟队列是一项允许消息在传递给消费者之前保留一定时间的功能。
例如，当消费者应用程序需要额外的时间来处理消息时，此功能非常有用。
发送到延迟队列的消息将保留在队列中，对使用者不可见，直到指定的延迟时间过去。

默认（最小）延迟时间为 0 秒，可设置的最大延迟时间如下。

• 对于标准队列，最大延迟时间为 900 秒（15 分钟）
• 对于 FIFO 队列，最大延迟时间为 900 秒（15 分钟）

对于标准队列，更改队列延迟设置不会影响队列中已有消息的延迟。
新设置仅适用于设置更改后添加的消息。
同样，对于 FIFO 队列，配置更改不会影响现有消息，而仅适用于新消息。

延迟队列与可见性超时类似，但两者之间的主要区别是：

• 延迟队列：消息添加到队列后立即隐藏
• 可见性超时：消息从队列中检索后隐藏

如果您想为单个消息指定延迟时间而不是为所有消息设置统一的延迟时间，请使用下面描述的消息计时器。
消息计时器允许您为单个消息设置自己的延迟时间，最长可达 900 秒（15 分钟）。
这与队列级DelaySeconds属性的最大值相同。
如果同时设置了队列级DelaySeconds属性和消息计时器DelaySeconds值，则消息计时器值优先。
换句话说，如果设置了消息计时器，则队列的DelaySeconds值将被忽略。

通过使用延迟队列和消息计时器，您可以为整个队列设置默认延迟时间，同时为特定消息指定单独的延迟时间。

消息定时器

Amazon SQS 的消息计时器功能允许您为添加到队列的每条消息指定初始隐藏期。
这提供了一种机制，即使消息到达队列，消费者也不会看到它，直到经过一定的设定时间。
例如，计时器为 45 秒的消息在到达队列后的前 45 秒内对消费者不可见。

最小（默认）延迟时间为 0 秒，但您可以将最大延迟设置为 15 分钟。
使用 AWS 管理控制台、AWS SDK 等发送消息时可以设置消息计时器。

但是，FIFO（先进先出）队列无法为单个消息设置此计时器。
如果要延迟 FIFO 队列中的消息，则必须使用延迟队列，它为整个队列设置延迟周期。
此外，在单个消息上设置的消息计时器优先于在 Amazon SQS 延迟队列上设置的DelaySeconds值。
这意味着消息计时器设置优先于延迟队列设置。

可见性超时、延迟队列和消息计时器之间的差异

可见性超时、延迟队列和消息计时器之间的主要区别总结如下。

•  延迟队列
   消息添加到队列后立即隐藏。
  延迟队列是在队列范围内设置的，因此延迟会应用于添加到队列中的每条消息。此延迟会阻止消息在消费者指定的时间过去之前被检索。
•  可见性超时
   从队列中检索消息后，消息将被隐藏。
  这是一种设置，使消息在被消费者读取后的一段时间内对其他消费者不可见。这可以防止重复的消息处理，并让消费者有时间完成消息的处理。
•  消息定时器
   您可以为单个消息设置延迟时间。
  这允许您单独控制将特定消息添加到队列和向使用者显示之间的时间。消息计时器允许您为各个消息设置不同的延迟时间，并且与延迟队列不同，它们允许在逐条消息的基础上进行更详细的延迟管理。

 临时队列

Amazon SQS 的临时队列功能提供可供客户端和服务器之间的应用程序临时使用的队列，例如在请求-响应模式中。
提供“临时队列客户端”，在应用管理下动态生成这个临时队列，高效实现高吞吐量并降低成本。

该客户端自动将为特定进程按需创建的多个临时队列映射到单个 Amazon SQS 队列。
即使每个临时队列的流量较低，这也允许应用程序减少 API 调用并提高吞吐量。
此外，当不再需要临时队列时，客户端会自动删除它。
即使使用客户端的所有进程没有完全关闭，也会发生这种情况。

 临时队列的优点是：

• 充当专用于特定线程或进程的轻量级通信通道
• 可以创建和删除，而不会产生额外费用
• API 与非临时队列的静态（常规）Amazon SQS 队列兼容（您可以使用现有代码发送和接收消息）

例如，在服务器端，您可以创建一个LoginServer类来处理登录请求，并启动一个线程来轮询来自客户端的登录请求，并为每条消息调用handleLoginRequest()方法。
在handleLoginRequest()方法内部，调用doLogin()方法进行登录处理。

此外，为了确保队列清理，当应用程序不再使用临时队列客户端时，应调用shutdown()方法。
同样，您还可以使用AmazonSQSRequester接口的shutdown()方法。这可确保正确删除临时队列并防止浪费资源。

需要临时消息交换（例如请求-响应模式）且可以利用 Amazon SQS 临时队列功能的应用程序的具体示例包括：

•  Web应用程序登录流程
  用户在登录表单中输入的信息从Web服务器发送到后端服务器，并接收认证结果的过程。在这种情况下，为每个登录请求创建一个临时队列并使用它与后端服务器通信，可以实现高效且独立的消息交换。
•  与外部API合作
  应用程序向外部 API 服务发送请求并接收响应的过程。例如，在与支付服务或社交媒体 API 集成时，您可以通过使用临时队列来管理请求和响应消息交换来提高稳定性和可扩展性。
•  异步文件处理
  在后台异步处理用户上传的文件的应用程序。在这种情况下，使用临时队列来管理文件处理请求可以使后台处理高效运行，同时保持用户界面响应。
•  聊天应用程序
  用于在用户之间交换消息的聊天应用程序。您可以通过为每个用户的消息发送请求创建临时队列并使用它来管理消息传递和接收来实现可扩展的实时消息交换。
•  分布式处理系统
  跨多个工作节点分发和执行大规模数据处理的系统。您可以使用临时队列来管理作业分配并在工作节点之间传递中间结果，以实现高效且容错的分布式处理。

在这些示例中，您可以利用临时队列的动态创建和删除、高吞吐量和成本效率以及独立的通信通道来提高应用程序性能和可扩展性。

基于属性的访问控制 (ABAC)

借助 Amazon SQS，基于属性的访问控制 (ABAC) 允许您使用 IAM 策略基于标记的用户和 AWS 资源来管理细粒度的访问权限。
这允许经过身份验证的 IAM 委托人根据与 SQS 队列关联的标签或别名授予对 Amazon SQS 队列的访问权限，而无需编辑策略或管理权限。

ABAC 允许您通过使用为每个业务角色添加的标签配置 IAM 权限来扩展权限管理。
它还使您不必每次添加新资源时都更新策略。
此外，您可以通过标记 IAM 委托人并设计策略来创建 ABAC 策略，以便在 IAM 用户角色上的标签与 Amazon SQS 队列上的标签匹配时允许 Amazon SQS 操作。

使用 ABAC 的好处包括减少为不同角色创建不同策略的需要，减轻运营负担。
此外，成员可以快速扩展，并在正确标记后自动授予新资源的权限。
此外，您可以使用 IAM 委托人权限来限制资源访问并跟踪哪些用户正在通过 AWS CloudTrail 访问您的资源。

特定的 ABAC 控制包括创建 IAM 策略，该策略仅允许在资源标签或请求标签与特定键和值匹配的条件下对 Amazon SQS 队列进行操作。
您还可以使用 AWS 管理控制台或 AWS CloudFormation 通过 ABAC 策略创建 IAM 用户和 Amazon SQS 队列。

正确使用 ABAC 可以使 Amazon SQS 更加安全和灵活，从而实现高效的资源管理，同时满足组织安全要求，尤其是在大型环境中。

 亚马逊 SQS 最佳实践

标准队列和 FIFO 队列通用的最佳实践

建议采用以下最佳实践，以高效且经济高效地使用 Amazon SQS。这些东西适用于标准队列和 FIFO 队列。

•  高效处理消息
  根据收到消息后处理和删除消息所需的时间适当设置可见性超时。可见性超时的最大值为 12 小时，但请注意，您可能无法为每条消息将其设置为完整值。此外，如果消息处理时间未知，您应该考虑设置初始可见性超时，然后在工作时定期增加它。

•  处理请求错误
  使用 AWS 开发工具包时可以使用自动重试和退避逻辑。如果您不使用 SDK，请确保等待一定时间后再重试 ReceiveMessage 操作。希望以指数方式缩短等待时间。例如，第一次重试前等待 1 秒，第二次将等待时间增加到 2 秒，第三次增加 4 秒，依此类推。

•  配置长轮询
  通过使用长轮询，可以避免不必要的轮询并降低成本。 WaitTimeSeconds 参数最多可设置为 20 秒。请注意，HTTP 响应超时时间必须设置得长于该参数。例如，如果将 WaitTimeSeconds 设置为 20 秒，则将 HTTP 响应超时设置为 30 秒或更长。

•  捕获有问题的消息
  配置设置以将难以处理的消息移至死信队列并获取准确的 CloudWatch 指标非常重要。通过将无法处理的消息移至死信队列，您可以隔离有问题的消息并调查错误原因，而不会减慢主队列中的处理速度。

• 死信队列保留期设置 死信队列 (DLQ) 允许您暂时存储无法成功处理的消息，并在以后查看它们以解决问题和分析问题。因此，DLQ的消息保留时间一般设置得比普通队列长。这使您有足够的时间来调查和解决有问题的消息。标准队列和 FIFO 队列的处理有所不同，如下所示。
  标准队列：当消息移动到死信队列时，它会保留入队时的时间戳，并从该点开始持续一段保留期。
  FIFO 队列：当消息移动到死信队列时，时间戳会重置并开始新的保留期。
  这样，根据队列类型，对 DLQ 保留期进行不同的管理。理解这种区别对于设计和管理有效的消息处理系统非常重要。

•  避免消息处理不一致
  分布式系统特有的一个问题是，消息可能被标记为已发送，但消费者并未收到。因此，不建议将死信队列的最大接收数设置为1。通过将最大接收次数设置为 2 次或更多，可以降低由于临时错误而丢失消息的风险。

•  实施请求-响应系统
  在实现请求-响应模式或 RPC（远程过程调用）系统时，有效使用回复队列（客户端用来接收服务器响应的消息队列）非常重要。不要为每条特定消息创建一个新的回复队列，而是在系统启动时为每个生产者（发送请求的一方）设置一个回复队列。此外，使用关联 ID 来匹配请求和响应可以简化回复队列管理并提高系统的整体性能。这使您能够有效地处理多个请求和响应，从而减少系统响应时间并优化资源。

• 降低成本您可以通过批处理消息操作并利用适用于 Java 的 AWS 开发工具包中包含的缓冲异步客户端，将客户端缓冲和请求批处理结合起来。这减少了 API 请求的数量并降低了成本。

•  使用适当的轮询模式
  建议使用长轮询以避免不必要的 ReceiveMessage 调用，即使队列为空也是如此。此方法通过将响应推迟到服务器收到消息或配置的等待时间到期来减少 API 调用次数并节省成本。另一方面，短轮询无论队列中是否有消息都会立即返回响应，因此它适合需要即时性的应用，但也增加了成本，因为空响应也有可能被收取费用。因此，根据应用需求，综合考虑成本和响应速度，选择最佳的轮询模式非常重要。

 FIFO 队列的最佳实践

为了最有效地利用 Amazon Simple Queue Service (SQS) 中的 FIFO 队列，了解并正确应用一些最佳实践非常重要。下面介绍如何最好地使用消息重复数据删除 ID 和消息组 ID。

 使用消息重复数据删除 ID

•  确保消息的唯一性
  消息重复数据删除 ID 是确保发送的消息不重复的令牌。使用给定消息重复数据删除 ID 成功发送的消息将被接受，但不会在 5 分钟重复数据删除间隔内传送，以避免与使用相同 ID 发送的其他消息错误地传送。这可以防止消息重复并确保唯一性。

•  提供消息去重ID
  生产者必须为具有完全相同的消息正文、具有相同内容但不同属性的消息或即使内容不同（包括重试次数）SQS 也应视为重复的消息指定消息重复数据删除 ID。这使得 SQS 能够正确处理重复的消息。

单一生产者/单一消费者系统中的重复数据删除

在具有单个生产者和单个消费者的系统上，对具有唯一主体的消息启用基于内容的重复数据删除。在这种情况下，生产者可以省略消息去重ID。此外，尽管消费者不需要提供传入请求尝试 ID，但最佳实践是这样做。这允许简单的系统设计。

 专为断电恢复而设计

FIFO 队列重复数据删除过程对时间敏感。在设计应用程序时，生产者和消费者必须能够从客户端和网络中断中恢复。特别是生产者需要注意SQS重复数据删除间隔为5分钟。如果中断持续超过 5 分钟，生产者必须使用新的消息重复数据删除 ID 重新提交消息。

 使用消息组 ID

•  实现消息分组
  具有相同消息组 ID 的消息将按照该消息组的严格顺序依次处理（不保证不同消息组之间的顺序）。处理队列中的多个有序消息组允许多个使用者进行处理，但每个用户的会话数据都以 FIFO 方式处理。这允许并行处理，同时保证组内的消息顺序。

多个生产者/多个消费者系统中的重复数据删除

在具有多个生产者和多个消费者且优先考虑吞吐量和延迟的系统中，建议为每条消息生成唯一的消息组 ID。这不能保证顺序，但可以消除重复。这有助于确保系统的可扩展性并防止消息重复。

 使用传入请求尝试 ID

•  请求重复数据删除
  如果您在长时间网络中断期间遇到开发工具包和 Amazon SQS 之间的连接问题，最佳实践是提供传入请求尝试 ID，并在开发工具包操作失败时使用相同的 ID 重试。这可以防止由于网络问题而多次接收同一消息。

通过正确应用上面列出的最佳实践，您可以最大限度地提高使用 Amazon SQS FIFO 队列的应用程序的性能和可靠性。根据您的系统要求选择和实施适当的最佳实践非常重要。

 总结

这次，我们创建了 Amazon SQS 的历史时间线，并查看了 Amazon SQS 功能的列表和概述。

Amazon Simple Queue Service (Amazon SQS) 是一种用于分布式计算环境的消息队列服务，于 2004 年首次作为 AWS 基础设施服务发布，并于 2006 年正式发布。
当 2004 年 11 月宣布这一消息时，人们的反应是“嗯？亚马逊为什么要这样做？”（参考： AWS 博客：第一个五年）。
近 20 年后，Amazon SQS 仍然提供更新的消息传递和队列、微服务架构、分布式系统和无服务器计算等现代计算的关键组件。
从目前的情况可以看出，Amazon SQS 发布时难以理解的愿景和设计理念，准确地捕捉到了未来的需求和系统架构的演变。

Amazon SQS 从一开始就优先通过 API 而不是 GUI 来使用，并且作为 IaaS，它可以作为独立的功能以松散耦合的方式与其他系统灵活链接，并且可以轻松应对使用目的的变化。 ，可以看出，当时Serverless、微服务、全托管服务的概念就已经实现了。