手动管理 SQS 队列与 Lambda 触发器

Question

我不确定这在 ServerFault 或软件工程上是否会更好，如果合适，我愿意移动这篇文章。

我们最近开始移动我们的一些数据处理管道以使用队列来管理单个数据位，而之前我们使用定时 lambdas 来提取自上次更改以来的所有数据。

在进行此更改时，我们注意到队列并没有像我们首先预期的那样工作 - 我们认为 lambda 只会将项目从队列中拉出，因为 lambdas 可用。相反，aws 管理的 lambda 触发器似乎抓取了一大块消息（最多十个）并将其扔给 lambda 服务。如果 lambda 不可用，则消息会受到限制，然后在退避时间后重播，直到我们配置的重播“错误”限制（五）。之后，它被扔进我们的死信队列。

我们每天都会看到一些消息由于节流而最终进入死信队列。然后我们将它们放回主队​​列（我们每隔几个小时就有一个流程）。然而，我们并不能 100% 确定节流是事情被推迟的原因，因为没有任何迹象表明消息被转移的原因——我们只是假设了这么多，因为我们没有收到这些消息的任何错误日志。我们联系了 Amazon 支持人员询问此问题，他们确实能够确认消息实际上是由于节流而“出错”。

我们进一步询问了他们对此的建议 - 这一定是一个常见问题，对吧？他们首先建议提高我们的重播限制，这似乎是一个明显的不可行。任何失败都会发生重放，所以当我们的 lambdas 出现错误请求时，它们只会受到重击。还被问及是否有任何方法可以区分错误，因为我们不关心限制，如果需要，我们很乐意让这些重试十几次 - 但没有。他们的另一个建议是从我们的 lambdas 中自己管理队列。在我们的 lambdas 中构建我们自己的代码来提取消息，然后在处理后删除它们。不过，这似乎真的有悖常理——为什么每个 AWS 消费者都要构建自己的基础设施？

所以我想我的问题是，其他人正在这样做吗？你在使用内置的 lambda 触发器吗？您是否正在创建自己的代码来管理队列消耗？您是否看到这些限制，或者我们可以做些什么不同的事情？管理此问题的其他服务有什么不同吗？

Answer 1

最佳做法是处理代码中的错误并手动删除成功的消息。这使您可以处理有害消息，而无需再次重新处理好消息。节流阀不应该经常出现在 DLQ 中。 re:Invent 2020 的这段视频很好地解释了它的工作原理。 Scalable serverless event-driven architectures with SNS, SQS & Lambda。从大约 20 分钟开始进入 SQS 错误处理。