lambda 重试逻辑是否适用于标准 sqs 调用？答案

【问题标题】：Will lambda retry logic work with standard sqs invocation?lambda 重试逻辑是否适用于标准 sqs 调用？
【发布时间】：2021-01-11 14:42:46
【问题描述】：

我的项目流程是：

CloudWatch >> SQS >> Lambda

Cloudwatch 调用标准 SQS，SQS 调用 lambda 函数。

根据文档，lambda 重试逻辑在异步调用中工作，但是 SQS 基于轮询机制并遵循同步行为。这是我的理解。

问题：-

我用两个场景测试了我的代码：-

lambda retry 0 ：那时一切正常，我的 lambda 运行了 3 次。
Lambda retry 2 :- 那时 lambda 重试，messageId 是 2 个不同的 id，lambda 函数运行 6 次。

第二个场景的输出：-

2020-09-24T20:02:52.222+05:30
MessageId : 5a8f5dbd-b07d-4c80-9d34-e5efb1002b3b
ApproximateReceiveCount:1

2020-09-24T20:03:51.047+05:30
MessageId :15ae23e3-472c-4d6e-99a6-8a248dae353e
"ApproximateReceiveCount": "1"

2020-09-24T20:07:50.863+05:30
MessageId :5a8f5dbd-b07d-4c80-9d34-e5efb1002b3b
"ApproximateReceiveCount": "2"

2020-09-24T20:08:50.963+05:30
MessageId :15ae23e3-472c-4d6e-99a6-8a248dae353e
"ApproximateReceiveCount": "2"

2020-09-24T20:12:50.652+05:30
MessageId :5a8f5dbd-b07d-4c80-9d34-e5efb1002b3b
"ApproximateReceiveCount": "3"

2020-09-24T20:13:50.347+05:30
MessageId :15ae23e3-472c-4d6e-99a6-8a248dae353e
"ApproximateReceiveCount": "3"

Sqs 可见性超时为：5 分钟。

所以，我的问题是
上述数据行为的原因可能是什么？
根据我的项目流程，lambda 重试逻辑应该可以工作吗？

【问题讨论】：

你能解释一下你的意思吗？哪个lambda retry 0？哪个选项确切；是吗？什么消息，您是手动提交的吗？他们有多少？观察到的行为有什么问题？
在 lambda 重试选项中，我们有 0、1、2 个选项。此功能允许用户设置 lambda 在失败时重试的次数。

标签： node.js amazon-web-services lambda aws-lambda amazon-sqs

【解决方案1】：

在我看来，对“lambda retry option we have 0, 1, 2 options”及其与event source mapping with sqs的关系存在一些误解。

重试选项在这种情况下不适用。您可以将其设置为您想要的任何值，它不会影响重试将您的 sqs 消息传递给 lambda。这是因为这种情况下的重试仅由 SQS 设置控制。来自docs：

事件源映射对于从队列中读取的事件源映射，您可以通过配置可见性超时和strong>源队列上的重新驱动策略。

换句话说，您的情况下的重试仅受 SQS 队列设置控制，而不是 lambda。

【讨论】：

是的..我也有同样的理解。那么意味着 lambda 重试机制在使用 SQS 时将不起作用吗？
@PratapChauhan 是的。该选项无效。它全部在 SQS 端进行管理。
谢谢 .. 我也有同感，但有时我会看到奇怪的行为。如果您检查上面发布的日志......那些假设是 3 个日志，因为 maxcount 是 3，但我收到了 6 个日志，前两个日志只有 1 分钟的差异，ApproximateReceiveCount 为 1，messageID 不同，下一个日志相同。所以我觉得 lambda 重试在这里也有效，否则可能因为我的代码问题而发生。
@PratapChauhan 一定还有其他事情发生，这在您的问题中并不明显。我建议使用 sqs 创建最基本的 lambda，并对其进行试验以及在函数抛出异常时重试如何工作。