当前位置: 首页 > 知识库问答 >
问题:

AWS SQS死信队列通知

严锐
2023-03-14

我正在尝试设计一个基于SQS、Lambda和SNS的小型消息处理系统。在失败的情况下,我希望将消息排入死信队列(DLQ)中,并调用webhook。

目前,如果一切顺利,流程应该是这样的:

  1. SQS(用于处理重试)将消息排入队列
  2. lambda由SQS调用并处理消息
  3. lambda发送webhook,并正常完成

如果lambda中的某些东西出错(无法调用success webhook,无法处理手头的任务),实现我想要的最简单的方法似乎是设置一个DLQ1,SQS将失败的消息放入DLQ1中。然后将调用一个辅助lambda来处理该消息,将其传递给SNS,SNS将调用失败的webhook,并且还将该消息转发给DLQ2,即最终的/真的DLQ。

我知道的另一种选择是警报,尽管有人警告我它们相当棘手。另一种方法是,如果上次重试失败,让lambda调用错误报告webhook,尽管这似乎不合适。

谢谢!

共有1个答案

艾骏
2023-03-14

在成功的情况下,您的体系结构看起来已经足够好了,但我个人认为,如果出现任何问题,这是相当令人困惑的,因为我不明白为什么您需要两个DLQ开始。

在失败的情况下,我会这样做:

  1. 在源SQS队列上定义一个DLQ,并将maxReceiveCount设置为3,这意味着如果消息失败三次,它们将被重定向到配置的DLQ
  2. 创建侦听此DLQ的Lambda
  3. 在此lambda中执行webhook.
  4. 由于步骤3在处理完消息后会自动从队列中删除消息,而且您显然希望将消息保留在某个位置,因此可以将消息内容存储在S3上的文件中,并将文件元数据(bucket和key)存储在DynamoDB的表中,这样您就可以始终查询失败的消息。

我在这里没有看到SNS的任何作用,除非你想要一个给定的消息有多个订阅者,但我看到的情况并非如此。

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

 类似资料:
  • 死信队列(Dead Letter Queue)本质上同普通的Queue没有区别,只是它的产生是为了隔离和分析其他Queue(源Queue)未成功处理的消息。 创建死信队列的方法参见createQueue() API,与创建普通队列无异, 死信队列不可调用deadMessage(), deadMessageBatch API,其他操作都与对普通Queue的操作无异。 为了将源Queue的未能成功处理

  • 对于异步的触发器,平台会对函数失败的任务进行最多3次重试。 在新建触发器的时候,为触发器配置一条死信队列,从用户的EMQ队列中选择一条,用于接收函数失败的任务。 在设置死信队列前,请对group: CIf76b0600-24e9-42c4-acf3-d491fbd9fd71​ 授予 FULL_CONTROL 权限,若不授予权限,平台将丢弃失败的任务信息。 消息的内容如下,以后可能增加字段,请用户在

  • 我有一个lambda函数,我想为它创建一个SQS死信队列。我首先在Terraform中创建SQS: 这是来自Terraform的例子。但是,我被redrive_policy卡住了。 我是否正确理解,这为SQS队列设置了一个死信队列? 如果我设置了redrive_policy,这意味着我在一个DLQ上设置了一个DLQ。我觉得可以在DLQ上设置DLQ,在DLQ上设置DLQ,以此类推。 我找不到这方面的

  • 未创建我的exchange和dlq。我在下面的YML中有以下内容。我确实创建了一个匿名队列,但也没有发布消息。任何想法。

  • 什么是最好的方法来实现死信队列(DLQ)的概念在Spring Boot 2.0应用程序中使用sping-kafka 2.1. x有所有的消息被处理失败的@KafkaListener方法的一些bean发送到一些预定义的Kafka DLQ主题并且不丢失一条信息? 因此,Kafka的记录是: 已成功处理, 处理失败,并发送到DLQ主题, 处理失败,未发送到DLQ主题(由于意外问题),因此将再次被侦听器使

  • 我有一个使用Spring Cloud Streams-RabbitMQ在微服务中交换消息的项目。对我的项目至关重要的一件事是,我不能丢失任何信息。 null 我是这些框架的新手,我希望你能帮助配置我的...