Amazon Simple Queue Service
开发人员指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。请点击 Amazon AWS 入门,可查看中国地区的具体差异

适用于 FIFO (先进先出) 队列的建议

下列准则可帮助您最佳地使用消息重复数据删除 ID 和消息组 ID。有关更多信息,请参阅 Amazon Simple Queue Service API Reference 中的 SendMessageSendMessageBatch 操作。

使用消息重复数据删除 ID

消息重复数据删除 ID 为 用于已发送消息的重复数据删除的令牌。如果成功发送了一条具有特定消息重复数据删除 ID 的消息,则在发送时使用了同一消息重复数据删除 ID 的任何消息都会被成功接受,但在 5 分钟重复数据删除时间间隔内不会发出。

注意

消息重复数据删除应用于整个队列,而不应用于单个消息组。

  • 如果您有一位创建者和一位使用者并且消息都是唯一的 (因为消息正文中包含特定于应用程序的消息 ID),则应遵循下列准则:

    • 为队列启用基于内容的重复数据删除 (每条消息都具有唯一的正文)。创建者可忽略消息重复数据删除 ID。

    • 尽管使用者无需为每个请求提供接收请求尝试 ID,但最好提供,因为这样可以更快地执行失败-重试序列。

    • 由于请求不会干扰消息在 FIFO 队列中的顺序,因此您可重试发送或接收请求。

  • 创建者应为在下列情况下发送的每条消息提供消息重复数据删除 ID 值:

    • Amazon SQS 必须将其视为唯一项的包含相同消息正文的已发送消息。

    • Amazon SQS 必须将其视为唯一项的内容相同、但消息属性不同的已发送消息。

    • Amazon SQS 必须将其视为重复项的内容不同 (例如,包含在消息正文中的重试计数不同) 的已发送消息。

  • FIFO 队列中的重复数据删除过程具有时效性。设计应用程序时,应确保创建者和使用者均可在客户端或网络出现故障的情况下进行恢复。

    • 创建者必须知道队列的重复数据删除时间间隔。Amazon SQS 的最小 重复数据删除时间间隔为 5 分钟。在重复数据删除时间间隔过期后重试 SendMessage 请求可能会将重复的消息引入队列中。例如,车辆中的移动设备将发送其顺序很重要的消息。如果车辆在接收确认前一段时间失去手机网络连接,则在重新获得手机网络连接之前重试请求可能产生重复项。

    • 使用者必须具有可见性超时,以便将在可见性超时过期之前无法处理消息的风险降至最低。您可通过调用 ChangeMessageVisibility 操作延长处理消息时的可见性超时。但是,如果可见性超时过期,其他使用者可立即开始处理消息,从而导致多次处理消息。要避免这种情况,请配置死信队列

使用消息组 ID

消息组 ID 为 指定某条消息属于特定消息组的标签。属于同一消息组的消息总是严格按照与消息组有关的某个顺序逐一进行处理(但是属于不同消息组的消息则不会进行有序处理)。

  • 要交错单一 FIFO 队列中的多个有序消息组,应使用消息组 ID 值 (例如,多个用户的会话数据)。在此情况下,多个使用者可处理此队列,但每个用户的会话数据是按 FIFO 方式处理的。

    注意

    如果属于某个特殊消息组 ID 的消息不可见,则其他使用者可处理具有相同消息组 ID 的消息。

  • 在吞吐量和延迟比顺序更重要的情况下,若要在具有多个创建者和使用者的系统中避免处理重复消息,创建者应为每条消息生成一个唯一的消息组 ID。

    注意

    在此情况下,将消除重复项。但是,无法保证消息的顺序。

    存在多个创建者和使用者的任何情况都会增加无意中传递重复消息的风险 (如果工作线程在可见性超时内未处理消息,并且消息变得对其他工作线程可用)。

使用接收请求尝试 ID

接收请求尝试 ID 为 Amazon SQS 分配给每条消息的大型非连续编号。

在导致您的软件开发工具包和 Amazon SQS 之间产生连接问题的长时间网络中断期间,最佳实践是提供接收请求尝试 ID,并在软件开发工具包操作失败时使用相同的接收请求尝试 ID 进行重试。