

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon SQS 队列类型
<a name="sqs-queue-types"></a>

Amazon SQS 支持两种类型的队列：[**标准队列**](standard-queues.md)和 [**FIFO**](sqs-fifo-queues.md) 队列。使用下表来确定哪种队列最适合您的需求。


| 标准队列 | FIFO 队列 | 
| --- | --- | 
|  **无限制吞吐量** – 标准队列支持每个操作（[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 或 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)）每秒几乎无限次的 API 调用。这种高吞吐量使其非常适合需要快速处理大量消息的应用场景，例如实时数据流或大型应用程序。虽然标准队列会根据需求自动扩展，但您必须监控使用模式以确保实现最佳性能，特别是在工作负载较高的区域。 At-least-once 传@@ **送** — 有保证的传 at-least-once送，这意味着每条消息至少传送一次，但在某些情况下，由于重试或网络延迟，一条消息可能会多次传送。在设计应用程序时，您应该使用幂等性操作来处理可能出现的重复消息，从而确保多次处理同一条消息不会影响系统的状态。 **最大努力排序**：提供“最大努力排序”功能，这意味着虽然 Amazon SQS 尝试按照消息发送顺序传送消息，但不能保证这一点。在某些情况下，消息可能会无序到达，尤其是在高吞吐量或故障恢复的情况下。对于消息处理顺序至关重要的应用程序，您应该处理应用程序中的重新排序逻辑，或者使用 FIFO 队列来保证严格的排序。 **耐久性和冗余** — 标准队列通过在多个 AWS 可用区存储每条消息的多个副本来确保高耐久性。这样可以确保即使基础设施出现故障，消息也不会丢失。 **可见性超时**：Amazon SQS 让您能够配置可见性超时以控制消息在被接收后隐藏多长时间，从而确保在消息得到完全处理或超时到期之前，其他用户无法处理该消息。  | **高吞吐量** – 如果您使用[批处理](sqs-batch-api-actions.md)，则 FIFO 队列支持每个 API 方法（[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessageBatch.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessageBatch.html)、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 或 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessageBatch.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessageBatch.html)）每秒最多处理 3000 条消息。这种吞吐量依赖于每秒 300 次 API 调用，每次 API 调用都批量处理 10 条消息。通过启用高吞吐量模式，您可以将每秒事务数（TPS）扩展到 3 万个，但这会放宽消息组内的顺序要求。在不使用批处理的情况下，FIFO 队列支持每个 API 方法（`SendMessage`、`ReceiveMessage` 或 `DeleteMessage`）每秒最多 300 次 API 调用。如果您需要更高的吞吐量，可以通过 [AWS Support Center](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-sqs) 请求增加配额。要启用高吞吐量模式，请参阅[为 Amazon SQS 中的 FIFO 队列启用高吞吐量](enable-high-throughput-fifo.md)。 **仅处理一次**：FIFO 队列仅将每条消息传递一次，并在您处理和删除消息之前保持消息处于可用状态。通过使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 或基于内容的重复数据删除等功能，即使由于网络问题或超时而重试，也可以防止消息重复。 **First-in-first-out 传送** — FIFO 队列可确保您按照每个消息组中的发送顺序接收消息。通过将消息分配到多个组中，您可以并行处理这些消息，同时保持每个组内的顺序。  | 
|  ![\[标准队列消息传递。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-what-is-sqs-standard-queue-diagram.png)  |  ![\[FIFO 队列消息传递。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-what-is-sqs-fifo-queue-diagram.png)  | 
| 当吞吐量至关重要时，请使用标准队列在应用程序之间发送数据，例如：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html) |  如果事件顺序非常重要，可以使用 FIFO 队列在应用程序之间发送数据，例如： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html)  | 

# 在 Amazon SQS 中实现请求-响应系统
<a name="implementing-request-response-systems"></a>

实施请求-响应和远程程序调用 (RPC) 系统时，请记住以下最佳实践：
+ **在启动时创建回复队列**：在启动时为每个创建者创建回复队列，而不是为每条消息创建回复队列。使用关联 ID 消息属性高效地将回复与请求进行对应。
+ **避免在创建者之间共享回复队列**：确保每个创建者都有自己的回复队列。共享回复队列可能会导致创建者收到原本应发送给另一个创建者的响应消息。

有关使用临时队列客户端实施请求-响应模式的更多信息，请参阅 [请求-响应消息收发模式（虚拟队列）](sqs-temporary-queues.md#request-reply-messaging-pattern)。