由于各种原因，我在AWS上的消费者有时会从SQS队列中读取一些消息，并决定将其中一些消息放回队列中以便稍后处理。
我这样做的方法是将它们的VisibilityTimeout设置为0，这样其他消费者就可以立即看到它们。此处对此进行了记录。
问题是，在这样做几次之后，消息的ReceiveCount到达maxReceiveCount，这导致消息被移动到DLQ。我想知道是否可以以某种方式重置消息的ReceiveCount以避免这种情况。
我目前能想到的唯一选项是将消息的副本发送回队列的开头并删除原始消息。
我想知道是否可以以某种方式重置消息的ReceiveCount以避免这种情况。
遗憾的是，您无法重置，因为它是由SQS自动管理的。你无法控制它。
如果您不想使用多个SQS，一个用于不同的目的和消费者，我能想到的唯一解决方案就是简单地增加maxReceiveCount来考虑这些额外的读取。因此，如果您知道您的消息将被读取并返回到队列，比如说5次，那么将maxReceiveCount增加到8。这意味着，如果消息的读取次数是预期的3倍，则说明它有问题
这一切都取决于您的工作负载。DLQ上有一个lambda，它会将消息写回到主队列中进行重试，这并不罕见。然而，您通常会对消息进行一些转换，并向json数据包添加(例如(一个密钥，如dlq_retry_count。如果低于某个阈值，则DLQ lambda可以重试，或者删除该消息。
如果你只是继续接收DLQ消息，并在没有跟踪手段的情况下将其重新发送到队列中，那么你可能会得到一个充满毒丸消息的队列。