如何确保集成了SQS的Lambda调用的下游API在消息发送到DLQ之前至少被调用2次？
我将lambda使用SQS事件作为输入。SQS队列也有一个DLQ。lambda函数调用下游Restful API（调用此操作DoPostToAPI（）），我需要保证lambda函数尝试调用DoPostToAPI（）至少2次（在消息转到DLQ之前）
为了满足上述要求，我需要设置什么样的Lambda重试配置和SQS重新驱动策略？
我需要100%确定到达DLQ的消息只到达，因为它们已经尝试发送到下游API DoPostToAPI（）2次，并且如果可能的话，消息不会因为任何其他原因到达DLQ。
对我来说，只有在尝试操作时，消息才会到达DLQ，这是有道理的，而不是因为其他原因（例如，我不希望消息纯粹因为节流而到达DLQ，因为在发送到DLQ之前应该先尝试DoPostToAPI（）），如果lambda函数操作没有尝试，为什么我会希望消息到达DLQ？换句话说，我需要保证在项目移动到DLQ之前调用lambda操作。
我能得到一些帮助吗？由于DoPostToAPI（）api调用失败，是否可以保证DLQ上的消息已到达？或者（更不幸的是）消息到达DLQ的原因可能不是对下游API的调用失败？
从我目前在线阅读的内容来看，lambda在执行SQS消息上的接收并将消息移动到队列上的不可见位置后，可能会遇到节流问题并重新尝试lambda调用。但如果它再次遇到lambda节流，它可能会返回到主队列，如果它达到其最大接收计数，则可以在根本没有尝试lambda的情况下将消息放在DLQ上。这是正确的吗？
为了简单起见，让我们想象以下输入
- sqsque1
lambda“最大重试次数”和SQS重新驱动策略“maxReceiveCount”之间的相互作用是什么
共有1个答案
为了确保使用SQS时lambda尝试重试，只需设置SQS属性
maxReceiveCount
此值控制在消息发送到死信队列之前，将为给定批次尝试多少lambda调用。
不幸的是，lambda财产
maximum_retry_attempts
不适用于使用SQS作为函数事件触发器的lambda函数。
-
我有一个连接到lambda的队列（fifo）。我想在lambda中向标准队列发送一条消息。但没有发送/接收任何消息。然而，如果我尝试从非SQS连接的lambda（通过AppSync）发送它，它会工作。 我查过： lambda有权发送SQS消息（您可以在那里看到） 由于我已成功地从另一个lambda（非SQS）向标准队列发送消息，因此正确配置了标准队列 SQS URL是否正确 控制台中不会显示任何错
-
我有类似这样的结构 SQS->lambda->DLQ 但是，当lambda在向SQS添加新消息时被触发，然后失败时，消息不会存储在DLQ中。 我发现当新消息发布到SQS时触发的事件本质上是同步的。 SQS事件触发器异步调用lambda 或
-
我在配置了DLQ的SQS队列上有一个lambda触发器。 当我的lambda失败时，来自队列的原始消息将被重定向到DLQ。现在我想添加更多的信息到这个原始的消息（如为什么有一个错误等）。我知道我不能修改原始消息，但我看到消息可以有额外的消息属性。 如何从lambda函数（NodeJS）使用/设置它们？
-
TLDR；在主题交换和由使用者动态创建的队列的上下文中，当没有使用者使用消息时，如何重新传递消息/通知生产者？ 我有以下组件： null 生成器使用向exchange发送消息。 每个使用者创建一个队列，并为一组路由密钥（例如，Pictures.*和Videos.Trending）将交换绑定到这个队列。 当使用者处理完文件后，它会将结果推送到processing_results队列中。 现在--这工
-
目前我正在使用SQS-Lambda集成 Lambda的并发可用。SQS批次设置为1记录，0延迟。 SQS的可见性超时为15分钟，Lambda最大执行时间为15分钟 我会注意到，有时SQS消息在飞行中被卡住，根本没有被任何Lambda处理（它们在15分钟后落入死信队列，CloudWatch显示没有Lambda被消息调用） 有人面临过同样的问题吗？ 我在VPC内部运行Lambda，如果这很重要的话
-
我计划使用AWS FIFO SQS在我的数据存储中记录每个项目的当前状态。我将使用每个项目的唯一标识符作为messageGroupId，以确保对每个项目的消息进行严格排序。 SQS是否确保如果属于特定组的消息在DLQ中，则在DLQ消息被删除或重新驱动回主队列之前，该组的消息对消费者不可见？ 例如，可以按顺序接收以下三条消息： 我的轮询器成功地消耗了M1，但无法处理M2。它一直尝试，直到maxRec