amazon-web-services - SQS fifo 队列在用作 lambda 触发器时不能确保单次交付

Question

我有一个 fifo 队列，它触发 lambda 并且这个 fifo 队列没有其他消费者。

我希望我的 lambda 不会收到任何重复项，因为我确保我的消息具有 uniqueid 并且启用了基于内容的重复数据删除，以便没有重复项。但正如文档所说

Amazon SQS FIFO queues ensure that the order of processing follows the message order within a message group. However, it does not guarantee only once delivery when used as a Lambda trigger. If only once delivery is important in your serverless application, it’s recommended to make your function idempotent. You could achieve this by tracking a unique attribute of the message using a scalable, low-latency control database like Amazon DynamoDB.

这是否意味着即使启用了重复数据删除，我也会收到我的 lambda 副本，其中它是 fifo 队列的唯一使用者？

Answer 1

这里有两件事在起作用，你似乎混合在一起。

一方面，有 SQS 的 交付模型。使用 SQS FIFO 队列，您正确地注意到它启用了一次性交付。

另一方面，Lambda 函数 有 执行模型。执行模型是至少一次。顺便说一下，这与任何并发设置无关。

Lambda 可能会多次执行一个函数有多种原因。最值得注意的是，Lambda 具有内置的重试功能，并且独立于 SQS FIFO 队列。根据可能发生的错误类型以及您的 Lambda 代码具有什么样的外部可观察副作用，您可能会看到您的代码针对单个实际调用多次运行。

也就是说，发送到 SQS FIFO 队列的消息最终可能会被 Lambda 多次处理还有其他原因。例如，如果您的 Lambda 函数花费比队列或消息的 VisibilityTimeout 设置更长的时间来完成处理它收到的整个批次，那么所有这些消息将在队列中再次变为可见，并且您的 Lambda 函数的另一次调用将(当然，不仅仅是“可能”)再次收到这些消息。

所以底线是:您需要在 Lambda 中编写幂等代码 - 不是因为 SQS FIFO(它确实允许防止重复交付)，而是因为 Lambda 重试和消息在队列中再次变得可见的可能性由于处理缓慢(它总是至少一次执行模型)。