AWS Lambda 更快的处理方式

Question

目前，我正在实施基于 S3、Lambda 和 DynamoDB 的解决方案。 我的用例是，当在 S3 上上传新对象时，会调用第一个 Lambda 函数，下载新文件，将其拆分为大约 100 个（或更多）部分，并为每个部分添加额外信息。下一步，每个部分将由第二个 Lambda 函数处理，在某些情况下，将在 DynamoDB 中执行插入。

我的问题只是关于调用“第二个 lambda”的最佳方式。我的意思是，更快的方法。我想同时执行 100 个 Lambda 函数（如果我要处理 100 个零件）。

我知道有不同的可能性：

1) 我的第一个 Lambda 函数可以将每个部分作为一个项目推送到 Kinesis 流中，而我的第二个 Lambda 函数将做出反应、检索一个项目并对其进行处理。在这种情况下，我不知道 AWS 是否会在每次流中有剩余项目时启动一个新的 Lambda 函数。也许有一些限制......

2) 我的第一个 Lambda 函数可以推送 SNS 主题中的每个部分，然后我的第二个 Lambda 将对每条新消息做出反应。在这种情况下，我对延迟（通过 SNS 主题发送消息的操作与要执行的第二个 Lambda 函数之间的时间）有一些疑问。

3) 我的第一个 Lambda 函数可以通过执行 API 调用和传递信息直接启动第二个。在这种情况下，我不知道是否可以同时启动 100 个 Lambda 函数。我想我会被 AWS API 的速率限制所困（我说过，我想！）

有人有关于我的用例的反馈和建议吗？还有一次，对我来说最重要的是拥有更快的处理方式。

谢谢

Answer 1

Lambda 限制已到位以提供一些合理的默认值，但许多工作负载很快就会超过这些限制。您可以请求增加，因此这不会成为您的用例的瓶颈。本文档描述了该过程： http://docs.aws.amazon.com/lambda/latest/dg/limits.html

我不确定您的用例可以容忍多少延迟，但我经常使用 SNS 进行扇出，并且延迟通常是下一次调用的亚秒级（除非它是 Java/冷启动）。

如果延迟非常敏感，那么您可能希望直接使用 Invoke with the InvocationType set to "Event" 调用 Lambda。这将在您Invoke 100 次时最大限度地减少阻塞。如果您想进行超优化，您还可以将这些 Invoke 调用线程化到您的主 Lambda 函数中，以进一步提高并行度。

冷容器有时会导致调用延迟。如果以毫秒计，这可能会变得很棘手。试图超优化 Lambda 处理时间的人有时会使用立即返回的“心跳”事件来安排他们的 Lambda 函数的执行（因此处理时间很便宜）。这些容器将在一小段时间内保持“温暖”，这使它们能够接收您的事件而不会产生“冷启动”时间。 Java 容器的启动速度比 Node 容器慢得多（我假设 Python 可能与 Node 一样快，尽管我没有测试过）。