Lambda 和 SQS 重试策略

Question

寻找有关使用 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 次调用左右。

Answer 1

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

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

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