为什么异步事件源需要很长时间才能触发我的 Lambda 函数？

1 分钟阅读

异步事件源触发我的 AWS Lambda 函数时发生延迟。

概述

对 Lambda 函数使用异步调用时，您可能会注意到，触发事件所需的时间比预期要长。或者，您的事件可能会被发送到死信队列 (DLQ)，而不会被 Lambda 服务选取进行进一步处理。

有几种不同的 AWS 服务会异步调用 Lambda 函数：

通常，您可能会看到由于处理请求的异步方法而导致的延迟。

当您发出请求时，它会被发送到一个内部异步队列。Lambda 从该内部异步队列选取请求，然后将请求发送到 Lambda 函数进行进一步处理。如果 Lambda 函数出现错误，您可能会在函数的 Amazon CloudWatch 日志中看到延迟。如果请求在函数级别节流，则也会出现延迟。
如果在函数级别没有错误或节流数据点，请检查区域级别指标是否存在错误和节流。如果异步调用其他函数，然后遇到错误，则这些函数会明显延迟。因此，即使您的函数没有错误或节流数据点，对该函数的调用或请求仍可能延迟。
如果与您的 Lambda 函数位于同一区域的其他函数多次异步调用，则内部队列将变得拥塞。要解决此问题，请提高区域级别并发性。
要查看内部队列积压工作，请对 Lambda 函数启用 AWS X-Ray。当 AWS X-Ray 启用时，您可以使用停留时间属性。此属性显示在 Lambda 服务将请求发送给 Lambda 函数进行处理之前，请求在内部队列中花费的总时间。
设置每函数并发性或预留并发性，以保护函数免受队列积压工作的影响。

Lambda 是一种分布式服务，它确保您的函数至少调用一次。但是，如果函数调用多次，则可能会发生重复。请查看 CloudWatch 日志，了解是否存在这些重复调用。

最佳做法是确保您的函数可以处理重复请求。有关详细信息，请参阅如何让我的 Lambda 函数保持幂等性？
查看 Lambda 的 CloudWatch 日志，检查您的函数的请求 ID。从日志中，您可以检查重复事件的请求 ID 是相同还是不同。在 Lambda 异步调用的整个生命周期中，请求 ID 将保持不变。如果请求 ID 相同，请检查该函数是否有任何错误数据点导致调用重试和重复。
如果请求 ID 不同，则重复调用会发生在客户端。

查看 CloudWatch 日志，区分缺失调用和延迟调用。对于延迟调用，请按照本文的“延迟调用”部分中先前详述的步骤进行操作。

当没有足够的并发性来处理请求时，就会出现缺失调用。如果函数具有预留并发性，并且函数出现错误，则请求会在异步队列中停留很长时间。然后，无需由 Lambda 处理即可删除该请求。查看 AsyncEventsDropped 指标，检查在未运行函数的情况下丢弃的事件数量。

如果配置了 DLQ，请检查 DLQ 或请求的故障目的地。如果事件在六小时后在内部队列中过期，则可以将该请求发送到 DLQ，而无需由 Lambda 处理。

有关查看更多异步调用指标的详细信息，请参阅为 AWS Lambda 引入新的异步调用指标。