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

Question

我的架构是 AWS Gateway - 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 不是这项工作的合适平台。

Answer 2

1.处理文件并存储到事务表中。
我的问题是针对大文件的

API 网关有一些负载限制，因此它实际上不适合传递更大的负载。

大型内容的一个常见做法是使用 API 服务返回一个presigned url，客户端可以很容易地使用它来将内容上传到 S3

然后您可以使用另一个 API 资源或S3 events 来调用创建对象的操作（启动流程、批处理作业......）。

2.用户批准后处理数据到活动表。

现在的问题是什么是审批流程什么是“流程数据”，可能需要多长时间，需要哪些资源。

如果假设它是一个包含多个步骤的长时间运行的过程，则可以使用AWS Step Function 协调任务可能是一个不错的选择，但这取决于您的用例。

对于长期运行的作业，如果您设法将工作分解为可管理的部分，则可以使用 AWS Batch、EMR（或其他计算资源）甚至 SQS+Lambda。