0

寻找有关使用 SQS 优化 lambda 重试策略的输入。目前，我有一个由 S3 PUT 操作调用的 Lambda 函数，该函数发布到第三方网络钩子，我正在尝试解决来自所述网络钩子的可能错误/500。我设置了两个 SQS 队列用作重试策略，如下所示：

S3 PUT -> Lambda
Lambda throws error -> Retry twice ->
Move to first SQS queue -> Picked up by second Lambda function for re-processing ->
If re-processing lambda fails, put message back on queue ->
After 5 retries -> move to DLQ for manual evaluation

但是，在重新评估该策略后，我意识到我有两个 lambda 函数在做完全相同的事情（由 S3 PUT 触发的 lambda 和“重新处理”的 lambda，两者都只是点击了 webhook）。我的第二个想法是这样的：

S3 PUT -> SQS Queue ->
Lambda function to process queue message ->
Failed messages go back on queue ->
After X retries move to DLQ

这将消除对执行完全相同的事情的额外 lambda 的需要。是否有任何我没有考虑的可扩展性/成本问题？我能想到的拥有两个 lambda 的唯一好处是并发限制加倍，因为重试将由单独的函数处理。作为参考，这个过程的日吞吐量应该是每天 10-15k 次调用，偏高。

4

1 回答 1

0

选项二是要走的路，尽管您应该在放入队列的消息中跟踪您正在执行的重试次数，因为 SQS 不知道您已经重试了多少次，当您将消息放回队列中。

在扩展方面，如果您有一个或两个 Lambda 函数并不重要，因为 Lambda 无论如何都会横向扩展。您可以选择随时限制任何特定 Lambda 的实例数量，但默认情况下，您的账户中只有 1000 个并发执行的软限制。

您应该小心处理错误和重试的方式。当您收到 HTTP 500 系列错误时，服务可能会遇到严重问题，如果您重试重试，您可能无助于补救这种情况。缓解这种情况的常见策略包括指数退避 - 在每次重试之前等待更长的时间，并且通常不同的断路器模式。这些应该是您可以在研究中使用的关键字。您可以查看DelaySecondsSQS SendMessageAPI (文档) 中的参数来帮助您完成这些工作。

于 2021-03-05T20:52:40.163 回答