Node.js lambda重试逻辑能否与标准sqs调用一起工作？

我的项目流程是：

CloudWatch>>SQS>>Lambda

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

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

问题:-

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

lambda重试0:那一次我一切正常，我的lambda运行了3次

Lambda retry 2:-此时Lambda retries和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重试选项我们有0、1、2个选项”及其关系存在一些误解

在这种情况下，重试选项不适用。您可以将其设置为您想要的任何值，这对尝试将sqs消息传递给lambda没有任何影响。这是因为在这种情况下重试仅由SQS设置控制。发件人：

事件源映射对于从队列读取的事件源映射，可以通过配置源队列上的可见性超时和重新驱动策略来确定失败事件重试与目标之间的时间长度

---

换句话说，您的案例中的重试仅从SQS队列设置控制，而不是从lambda控制。

您能解释一下您的意思吗？哪个

lambda重试0

？哪种选择准确；是什么？什么消息，你是手动提交的吗？他们中有多少人？观察到的行为有什么问题？在lambda重试选项中，我们有0、1、2个选项。此功能允许用户设置lambda失败时应重试的次数。是。。我也有同样的理解。这意味着lambda重试机制在使用SQS时不会起作用，对吗？@PratapChauhan是的。这个选项没有效果。这一切都由SQS管理。谢谢。。我也有同样的感觉，但有时我会看到这种奇怪的行为。如果您查看以上发布的日志。。。那些假设是3个日志，因为maxcount是3，但我收到了6个日志，前两个日志只有1分钟的差异，ApproxiateReceiveCount是1，messageID是不同的，后面是相同的。所以我觉得lambda重试在这里也起作用了，或者可能是因为我的代码问题。@PratapChauhan一定有其他事情发生了，这在你的问题中并不明显。我建议使用sqs创建最基本的lambda，并尝试使用它，以及在函数引发异常时重试的工作方式。