【问题标题】:How to process DLQ messages during off-peak hours如何在非高峰时段处理 DLQ 消息
【发布时间】:2018-07-12 18:30:25
【问题描述】:

我们的请求目前受到外部 API 的速率限制,因此我们希望开发一种重试机制。

为此,我们决定使用连接到 Lambda 函数(调用外部 API)的 SQS(对所有请求进行排队)。默认情况下,3 次 Lambda 函数重试看起来不错,但有什么办法可以安排在 X 秒后重试(因为外部 API 在我们可以重试多少秒后返回)?

对于重试 3 次仍失败的请求,我们决定使用 DLQ(死信队列)并在非高峰时间处理这些请求。那么最好的方法是什么?我们目前正在考虑启动另一个仅连接到 DLQ 的消费者,通过 Scheduled Events Cron 触发。

如果 DLQ 中的请求失败了怎么办?我们仍然想处理这些。

谢谢

【问题讨论】:

  • 我想知道类似的情况,但还没有解决它。如果您要处理大量数据,一种可能性是使用 kinesis Streams 处理失败的请求并消除工作负载。我没做过所以不能推荐。否则,我的想法也是定期从 DLQ 重试。现在也可以直接从 SQS 触发 lambda,但这并不能解决您的平滑问题。
  • @macbutch 我实际上有一个解决方法。如果失败,我可以从 SQS 中删除消息,然后重新添加相同的消息,初始不可见期等于重试时间(从外部 API 获取)。这样我可以根据自己的需要构建自己的重试机制(SQS和DLQ)。 docs.aws.amazon.com/AWSSimpleQueueService/latest/…
  • 谢谢@Saad,实际上这似乎是一个非常好的方法。如果需要的话,我想我可以根据自己的情况调整它。

标签: amazon-web-services aws-lambda amazon-sqs


【解决方案1】:

我实际上有一个解决方法。如果失败,我可以从 SQS 中删除消息,然后重新添加相同的消息,初始不可见期等于重试时间(从外部 API 获取)。这样我就可以根据自己的需要建立自己的重试机制(SQS和DLQ)。

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-timers.html

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-12-23
    相关资源
    最近更新 更多