AWS SQS死信队列通知

Question

我正在尝试设计一个基于SQS，Lambda和SNS的小型消息处理系统。如果失败，我希望将消息放入死信队列（Dead Letter Queue，DLQ）中，并调用一个Webhook。

我想知道实现这一目标的最规范或最合理的方式。

当前，如果一切顺利，则过程应如下：

1. SQS（用于处理重试的地方）排队的消息
2. Lambda由SQS调用并处理消息
3. Lambda发送一个Webhook并正常完成

如果Lambda中出现问题（无法调用成功的Webhook，无法处理手头的任务），实现我想要的最简单的方法似乎是设置DLQ1，SQS会将失败的消息放入其中。辅助Lambda然后将调用它来处理此消息，将其传递到SNS，后者将调用失败Webhook，并将消息转发到最终/真实DLQ DLQ2。

那是最好的方法吗？

我知道的一种替代方法是Alarms，尽管我已经被警告说它们非常棘手。如果上一次重试失败，则另一种方法是让lambda调用错误报告webhook，尽管这在某种程度上似乎不合适。

谢谢！

Answer 1

如果成功的话，您的体系结构看起来就足够好了，但是我个人觉得如果发生任何问题，这很令人困惑，因为我不明白为什么您需要两个DLQ。

如果发生故障，我将采取以下措施：

1. 在源SQS队列上定义一个DLQ并将maxReceiveCount设置为ie 3，这意味着如果消息失败三遍，它们将被重定向到配置的DLQ
2. 创建一个监听此DLQ的Lambda。
3. 在此Lambda中执行webhook。
4. 由于第3步在处理完消息后会自动从队列中删除该消息，并且显然您希望将消息保留在某处，因此将消息的内容存储在S3上的文件中，并在其中存储文件元数据（存储桶和密钥）。 DynamoDB中的表，因此您始终可以查询失败的消息。

除非您希望给定消息有多个订阅者，否则我在这里看不到SNS的任何角色，但是据我所知并非如此。

这样，您只需要维护一个DLQ，就可以摆脱SNS，因为它只会给体系结构增加一层额外的复杂性。