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

# Amazon SQS 中的 FIFO 队列传递逻辑
<a name="FIFO-queues-understanding-logic"></a>

以下概念阐明了 Amazon SQS FIFO 队列如何处理消息的发送和接收，尤其是在处理消息排序和消息组时。 IDs

## 发送消息
<a name="FIFO-sending-messages"></a>

Amazon SQS FIFO 队列使用唯一的重复数据删除 IDs 和消息组来保留消息顺序。 IDs本主题重点介绍了消息组 IDs 对保持组内严格排序的重要性，并重点介绍了确保在多个生产者之间可靠且有序地交付消息的最佳实践。

1. **顺序保存**
   + 当多条消息连续发送到具有唯一消息重复数据删除功能的 FIFO 队列时 IDs，Amazon SQS 会存储这些消息并确认其传输。随后，这些消息将按其确切的传输顺序进行接收和处理。

1. **消息组 ID**
   + 在 FIFO 队列中，消息基于其消息组 ID 进行排序。如果多个创建者或线程发送具有相同消息组 ID 的消息，Amazon SQS 会确保按照消息的到达顺序进行存储和处理。
   + 最佳实践：为确保多个创建者之间的严格消息顺序，应为来自每个创建者的所有消息分配唯一的消息组 ID。

1. **按组排序**
   + **FIFO 队列逻辑应用于每个消息组 ID：**
     + 每个消息组 ID 表示一个不同的、有序的消息组。
     + 在每一个消息组 ID 内，所有消息的发送和接收均严格遵循一定的顺序。
     + 具有不同消息组的消息 IDs 可能会到达或处理顺序混乱。
   + **要求**：您必须将消息组 ID 与每条消息关联。如果消息发送时未指定消息组 ID，则操作将失败。
   + **单个组场景**：如果需要严格遵循一定的顺序处理所有消息，请为每条消息使用相同的消息组 ID。

## 接收消息
<a name="FIFO-receiving-messages"></a>

Amazon SQS FIFO 队列处理消息检索，包括批处理、FIFO 订单保证和请求特定消息组的限制。 IDs本主题介绍 Amazon SQS 如何在保持严格的排序和可见性规则的 IDs 同时检索消息组内和跨消息组的消息。

1. **批量检索**
   + 从包含多个消息组的 FIFO 队列接收消息时 IDs，Amazon SQS：
     + 尝试在单次调用中返回尽可能多的具有相同消息组 ID 的消息。
     + 允许其他使用者 IDs 同时处理来自不同消息组的消息。
   + **重要澄清**
     + 您可以一次性收到来自同一消息组 ID 的多条消息（使用 `MaxNumberOfMessages` 参数，一次调用最多可接收 10 条消息）。
     + 但是，在后续请求中，您无法接收来自同一消息组 ID 的其他消息，除非：
       + 当前接收到的消息被删除，或
       + 它们再次变为可见（例如，在可见性超时结束之后）。

1. **FIFO 顺序保证**
   + 批量检索的消息在组中保留其 FIFO 顺序。
   + 如果同一个消息组 ID 的可用消息少于 10 条，则 Amazon SQS 可能会在同一批次 IDs 中包含来自其他消息组的消息，但每个组都保留 FIFO 顺序。

1. **使用者限制**
   + 您无法显式请求接收具有特定消息组 ID 的消息。

## 多次重试
<a name="FIFO-retrying-multiple-times"></a>

创建者和使用者可以安全地重试 Amazon SQS FIFO 队列中失败的操作，而不会打乱消息顺序或引入重复消息。本主题重点介绍重复数据删除 IDs 和可见性超时如何确保重试期间的消息完整性。

1. **制作人重试**
   + 如果 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 操作失败，创建者可以使用相同的消息重复数据删除 ID 多次重试发送消息。
   + 只要创建者在重复数据删除间隔到期前收到至少一个确认，重试操作将：
     + 不会引入重复消息。
     + 不会打乱消息顺序。

1. **消费者重试**
   + 如果 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 操作失败，使用者可以根据需要使用相同的接收请求尝试 ID 重试多次。
   + 只要使用者在可见性超时结束之前收到至少一次确认，则重试：
     + 不会打乱消息顺序。

## 关于 FIFO 行为的其他注意事项
<a name="FIFO-behavior"></a>

了解如何处理可见性超时、启用多个消息组的并行处理以及确保在单组 IDs场景中进行严格的顺序处理。

1. **处理可见性超时**
   + 当消息被检索但未删除时，将保持不可见状态，指导可见性超时结束。
   + 在第一条消息被删除或再次可见之前，系统不会返回来自同一消息组 ID 的其他消息。

1. **并发和并行处理**
   + FIFO 队列允许并行处理不同消息组 IDs中的消息。
   + 为了最大限度地提高并发性，请设计具有多个消息组的系统， IDs 以实现独立的工作流程。

1. **单个组场景**
   + 要严格按顺序处理 FIFO 队列中的所有消息，请为队列中的所有消息使用单个消息组 ID。

## 示例（帮助更好地理解）
<a name="FIFO-examples"></a>

以下实际场景演示了 Amazon SQS 中 FIFO 队列行为。

1. **场景 1：单个组 ID**
   + 创建者发送了 5 条具有相同消息组 ID（Group A）的消息。
   + 使用者按照 FIFO 顺序接收这些消息。在使用者删除这些消息或可见性超时结束之前，不会接收来自 Group A 的其他消息。

1. **场景 2：多个群组 IDs**
   + 创建者向 Group A 发送了 5 条消息，向 Group B 发送了 5 条消息
   + Consumer 1 处理来自 Group A 的消息，而 Consumer 2 处理来自 Group B 的消息。这实现了并行处理，并在每个组内保持严格的顺序。

1. **场景 3：批量检索**
   + 创建者向 Group A 发送了 7 条消息，向 Group B 发送了 3 条消息
   + 单个使用者最多可检索 10 条消息。如果队列允许，它可能会返回：
     + 来自 Group A 的 7 条消息和来自 Group B 的 3 条消息（如果单组可用的消息不足，则返回的数量更少）。