【问题标题】:AWS SQS How can I reset a message's ReceiveCountAWS SQS 如何重置消息的 ReceiveCount
【发布时间】:2021-08-10 20:49:41
【问题描述】:

由于各种原因,我在 AWS 上的消费者有时会从 SQS 队列中读取一些消息,并决定将其中一些放回队列中以供稍后处理。

我这样做的方法是将他们的VisibilityTimeout 设置为 0,这使其他消费者可以立即看到它们。这记录在here

问题是在这样做几次之后,消息的ReceiveCount 到达maxReceiveCount,这导致消息被移动到DLQ。我想知道是否可以以某种方式重置消息的ReceiveCount 以避免这种情况。

我目前能想到的唯一选择是将消息的副本发送回队列的开头并删除原始消息。

【问题讨论】:

  • 我认为您的请求中缺少某些内容,您能解释一下为什么要退回这些消息吗?

标签: amazon-web-services amazon-sqs dead-letter


【解决方案1】:

我想知道是否可以通过某种方式重置消息的 ReceiveCount 以避免这种情况。

遗憾的是,您无法重置它,因为它由 SQS 自动管理。你无法控制它。

如果您不想使用多个 SQS,一个用于不同目的和消费者,我能想到的唯一解决方案是简单地增加 maxReceiveCount 以解决这些额外读取。因此,如果您知道您的消息将被读取并返回到队列中,假设 5 次,然后将您的 maxReceiveCount 增加到 8 个实例。这意味着如果消息被阅读的次数超过预期的 3 倍,则说明它有问题。

【讨论】:

    【解决方案2】:

    这一切都取决于您的工作量。在您的 DLQ 上有一个 lambda 将消息写回主队列以重试的情况并不少见。但是,您通常会稍微转换消息并(例如)向 json 数据包添加一个密钥,例如dlq_retry_count。然后,如果低于某个阈值,您的 DLQ lambda 可以重试或删除消息。

    如果您只是继续接收 DLQ 消息并将它们抽回到队列中而无法跟踪,那么您最终可能会得到一个充满毒丸消息的队列。

    【讨论】:

      猜你喜欢
      • 2019-11-11
      • 1970-01-01
      • 2020-07-27
      • 2020-10-28
      • 2022-08-24
      • 1970-01-01
      • 2018-02-11
      • 1970-01-01
      • 2020-05-01
      相关资源
      最近更新 更多