在SQS队列中使用多个消费者

Question

我知道可以使用多个线程使用SQS队列。我想保证每封邮件都会被消费一次。我知道可以更改消息的可见性超时，例如，等于我的处理时间。如果我的进程花费的时间超过可见性超时时间（例如连接速度慢），则其他线程可以使用相同的消息。

保证消息只处理一次的最佳方法是什么？

Answer 1

AWS SQS API在您使用API等读取消息时不会自动“消费”消息。开发人员需要自己打电话删除消息。

SQS确实有一个称为“重新驱动策略”的功能，作为“死信队列设置”的一部分。您只需将读取请求设置为1。如果消费进程崩溃，对同一消息的后续读取将把消息放入死信队列。

SQS队列可见性超时可设置为12小时。除非您有特殊需要，否则您需要实现进程将消息处理程序存储在数据库中以允许其进行检查。

Answer 2

收到消息时，将消息或消息引用存储在对消息ID具有唯一约束的数据库中。如果该ID存在于表中，则表示您已经收到它，并且数据库将不允许您再次插入它——因为存在唯一约束。

Answer 3

保证消息只处理一次的最佳方法是什么？

你要求的是保证——你得不到保证。您可以将消息被多次处理的概率降低到非常小的程度，但您不会得到保证。

我将解释原因，以及减少重复的策略。

• 当您将消息放入SQS中时，SQS可能会多次收到该消息
  • 例如：在发送消息时，一个轻微的网络故障导致了一个瞬时错误，该错误被自动重试-从消息发送者的角度来看，它失败了一次，成功发送了一次，但SQS同时收到了这两条消息
  • 与第一个示例类似——有很多计算机在幕后处理消息，SQS需要确保没有任何信息丢失——消息存储在多个服务器上，这会导致重复吗

  在大多数情况下，通过利用SQS消息可见性超时，来自这些来源的重复机会已经非常小——就像百分之一的一小部分。

  如果处理重复项真的没有那么糟糕（努力使消息消费幂等！），我认为这已经足够好了——进一步减少重复的机会是复杂的，而且潜在的成本高昂。。。

  好了，我们从兔子洞下去。。。在较高级别上，您希望为消息分配唯一的ID，并在开始处理之前检查正在进行或已完成的ID的原子缓存：

  • 确保您的消息在插入时提供唯一标识符
    • 没有这个，你将无法区分重复的。
    • 如果您的消息接收者需要开箱发送消息以进行进一步处理，那么它可能是另一个重复源（原因与上述类似）
    • InProgress条目应根据处理失败时恢复的速度设置超时
    • 根据您希望重复数据消除窗口的时间，完成的条目应该有一个超时
    • 最简单的可能是番石榴缓存，但只适用于单个处理应用程序。如果您有大量消息或分布式消费，请考虑为该作业建立一个数据库（使用后台进程来扫描过期的条目）
    • 不过，你可能负担不起无限的存储空间。
    • 请记住，如果没有所有这些，复制的机会已经相当低。根据邮件重复数据消除对您来说值多少时间和金钱，您可以跳过或修改任何步骤
    • 您的应用程序可以在处理消息后立即崩溃/挂起/执行很长的GC，但在MessageId为“已完成”之前（也许您正在为此存储使用数据库并且与它的连接已关闭）
    • 在这种情况下，“处理”最终会过期，另一个线程可以处理此消息（要么是在SQS可见性超时也过期之后，要么是因为SQS中有重复项）。