I'l*_*ack 9 amazon-sqs node.js aws-lambda
将消息添加到SQS队列中并将其配置为触发lambda函数(nodejs)之后。
触发lambda函数时-我可能想在5分钟后重试相同的消息,而不从队列中删除该消息。如果Lambda无法连接外部主机(例如API),我想这样做的原因-我想在5分钟后仅尝试3次再试一次。
如何用node js编写?
例如在Laravel中,我们可以Specifying Max Job Attempts发挥功能。尝试使用该作业的次数public $tries = 5;
资料来源:https : //laravel.com/docs/5.7/queues#max-job-attempts-and-timeout
我们如何在node.js中进行类似的处理?
我正在考虑将消息添加到另一个队列(以重试)。Lambda函数会在5分钟后从该队列中读取所有消息,然后将该消息发送回主队列,这将触发Lambda函数。
One*_*ema 15
重试和重试“超时”都可以直接在SQS队列中进行配置。
创建队列时,请设置以下属性:
该默认可见性超时会的时间,该消息将被隐藏一旦被你的应用程序接收。如果消息在lambda运行期间失败,并引发异常,则lambda 不会删除该批处理中的任何消息,并且最终所有这些消息都会重新出现在队列中。
如果您只想尝试3次,则必须设置SQS重新驱动策略(又称为“死信队列”)
重新驱动策略将使您的队列能够在将消息重新出现在队列N中次数(在N1到1000之间的数字)之后将消息重定向到死信队列(DLQ)。
必须理解,lambda将继续处理失败的消息(在代码中生成异常的消息),直到:
Message Retention Period期满(SQS删除消息)否则,Lambda将不会处理此错误消息。
根据我进行的几次实验,我了解了SQS集成的行为(有关重试的文档是模棱两可的ATM),lambda不会删除失败的消息并将继续重试它们。即使您设置了Lambda DLQ,消息也不会发送到DLQ,为此,它完全依赖于Lambda DLQ文档中所述的SQS队列的配置。
建议:
如前所述,如果在处理消息时代码中存在异常,则会重试整批消息,某些消息是否得到正确处理并不重要。如果由于某种原因下游服务失败,您可能会收到在DLQ中处理的消息。
建议:
博客文章“ Lambda并发限制和SQS触发器不能很好地混合(有时) ”描述了如何在您的并发限制设置得太低的情况下,lambda可能导致大量消息被限制,而接收到的尝试却从未被增加处理。
建议:
该帖子和亚马逊的建议是:
- 将队列的可见性超时设置为您在功能上配置的超时的至少6倍。
- 如果您的函数正在处理前一批批处理时,如果您的函数执行受到限制,则多余的时间将使Lambda重试。
- 将队列的重新驱动器策略上的maxReceiveCount设置为至少5。这将有助于避免由于节流而将消息发送到死信队列。
- 配置死信以将失败的消息保留足够长的时间,以便稍后可以将其移回以进行重新处理
Kan*_*yan 12
这是我如何做到的。
(Q1/Q2) SQS 触发器 --> Lambda L1(如果失败,在 (Q1/Q2) 上删除,在 Q2 上删除) --> On Failure DLQ
当消息到达 Q1 时,如果成功从那里开始,它会触发 Lambda L1。如果失败,将其丢弃到 Q2(这是一个延迟队列)。到达 Q2 的每条消息都会有 5 分钟的延迟。
如果您的初始消息可以有 5 分钟的延迟,那么您可能不需要两个队列。一个队列应该是好的。如果初始延迟不可接受,那么您需要两个队列。有两个队列的另一个原因是,您将始终有办法接收路径中出现的新消息。
如果您在处理 Q1/Q2 时遇到代码故障,aws 基础设施将立即重试 3 次,然后再将其发送到 DLQ1。如果您处理代码中的错误,那么您可以让管道按照您提到的时间工作。
SQS 延迟队列:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html
SQS Lambda 架构:
https://nordcloud.com/amazon-sqs-as-a-lambda-event-source/
| 归档时间: |
|
| 查看次数: |
4422 次 |
| 最近记录: |