amazon-web-services - 使用 AWS Gateway - Lambda - RDS 的长时间运行的作业

Question

我的架构是 AWS 网关 - Lambda - RDS我已将客户的数据作为 xlsx 文件。

我有两个步骤

1.处理文件并存储到事务表中。

2.用户批准后将数据处理到事件表。

我的问题是针对大文件，由于时间限制(AWS 网关 30 秒，Lambda 15 分钟)和同步过程，我无法完成流程。请建议我 AWS 中的任何服务都可以执行需要与 RDS 持续交互的长时间运行的作业，以将文件数据与系统数据进行比较。

Answer 1

通常您会希望所有HTTP 请求 尽可能短，这意味着您永远不会在HTTP 请求中执行任何实际工作。所有实际工作都将在 Lambda 函数中完成，这些函数是通过其他方式调用的，而不是 API 网关。一般流程是这样的:

1. 客户端上传大文件，作为返回获取此上传的唯一 ID。
2. 服务器将文件解析成数据库记录。
3. 服务器开始处理这些数据库记录。
4. 客户可以随时使用 id 查询处理状态。

举个例子，我用这种方式实现了这样一个系统:

1. 浏览器上传大型 Excel 文件，该文件逐行读取并写入数据库，一次成批数百行，所有行都标记有相同的随机 UUID。当请求结束时，该文件将自然丢弃。这种批量读取/写入经过优化，因此即使是非常大的文件也可以在几秒钟内推送到数据库中。
2. 作为结束上传过程之前的最后一个操作，SQS 消息与上传记录的 UUID 一起排队。
3. SQS 队列调用一个 Lambda 函数，该函数查询具有该 UUID 的所有记录，并将新的 SQS 消息放入队列中，每条记录都有各自的 ID，以几十个为一批(即“处理记录 1-20”的消息”、“21-40”等)。
4. 队列再次调用另一个 Lambda 处理程序，一个接一个地处理每条记录。

因此，大型上传已分解为单独的记录，然后是单独的批处理记录，然后单独处理每个记录，每个单独的步骤不会超过几秒钟，并分布在单独的 Lambda 实例中。

这不仅允许并行处理许多记录，而且永远不会接近 15 分钟的 Lambda 超时。 HTTP 请求也永远不会接近 30 秒的限制，因为初始的解析和存储步骤不会花费很长时间，并且每个后续请求只需要查看数据库的处理状态并且不需要任何事情本身。根据您的需要，即使初始的解析和存储步骤需要超过 30 秒，您也可以将文件上传到 S3，然后触发 Lambda 函数从那里处理它。

如果这些步骤中的任何，即使像这样最小化和分解，花费的时间超过 15 分钟的 Lambda 超时，那么 Lambda 不是完成这项工作的合适平台。