带 DLQ 的 SQS 扇出答案

【问题标题】：SQS fanout with DLQ带 DLQ 的 SQS 扇出
【发布时间】：2018-03-07 03:43:44
【问题描述】：

我正在考虑使用 SNS-SQS 服务向运行相同服务的机器提供更新。由于该计划不是让机器相互通信，因此我计划为每台机器创建一个 SQS（SQS 将在启动时创建）。

但是，我不确定在这种情况下如何使用死信队列 (DLQ)。每个 SQS 是否应该有自己的 DLQ，或者我可以拥有一个在该区域的 SQS 之间共享的通用 DLQ？我对前一种方法的担忧是会创建太多队列（2x 机器），而后一种方法的担忧是队列中可能存在同一消息的多个副本。

使用多个 SQS 队列时，最佳做法和推荐方法是什么？

【问题讨论】：

【解决方案1】：

我不会关心队列的数量 - 它们不花费任何费用 - 所以这实际上取决于您计划如何使用死信队列中的项目。我假设您将有某种流程来审查 DLQ 中的项目，以找出在过期之前未处理它们的原因。

如果不知道你打算做什么的细节，我认为单个 DLQ 会更好，如果你需要定期处理 DLQ 记录，处理应用程序/系统只需要监视那个单个队列。

在这种情况下看不到多个 DLQ 的优势，至少根据您的问题。

【讨论】：

是的。我倾向于有一个单一的队列。您对使用 DLQ 的假设是正确的。它主要用于审查未处理的内容。但是，如果消息没有被任何在其队列中侦听的服务器处理，则消息的所有副本都将在 DLQ 中结束（即 DLQ 中同一消息的多个副本）。这是一个通常遵循的约定吗？

【解决方案2】：

当您计划执行fanout process 时，拥有多个队列并没有什么坏处，只要它们用于异步处理即可。否则，首选单个队列。当您希望通过将其划分为多个队列并分别处理它们来同时处理几个任务时，通常使用扇出过程。 (to read more about fanout)

Dead Letter Queue (DLQ) 的目的是存储某个进程无法成功完成的消息。除非您的流程出现重大故障，否则将存储在 DLQ 中的元素数量应该非常少。因此，可以继续为所有其他 SQS 使用一个 DLQ。

拥有多个 DLQ 会带来开销，其中多个进程必须轮询 DLQ 以获取失败的消息。只有一个 DLQ 可以减少这种开销。

如果要存储不同类别的失败消息，建议使用多个DLQ。

【讨论】：