60 秒触发与 60 秒延迟 aws-lambda/RDS 错误消息？

Question

我们正在尝试在 Node 中创建这个 lambda 函数，它可以从 API 中播种 30 天的信息，但由于信息量很大，我们一次只能执行 1 天。我们目前这样做的尝试涉及使用一个函数，该函数一遍又一遍地从 lambda 本身中手动调用新的 lambda 实例，每次运行时从日期中减去 1 天，直到 HOW_MANY_DAYS_AGO > 0。我们将信息上传到 RDS数据库，然后运行计算结果的 sql 语句，然后将它们发布到网页。如果我们运行 lambda 10 天或以下，它工作得非常好。当我们尝试运行 30 天时，每次运行时都会在第 11 天或第 12 天左右开始出现此错误。我们尝试在整个代码中的不同位置设置延迟，因为我们假设事情发生得太快了。

18:27:53
2017-05-09T18:27:53.505Z e720be2f-34e4-11e7-90ca-3f2ffa915b81 { StatusCode: 
200, FunctionError: 'Unhandled', Payload: '{"errorMessage":"RequestId: 
3243f8d3-34e5-11e7-b0a2-df429a0d6565 Process exited before completing 
request"}' }
2017-05-09T18:27:53.505Z e720be2f-34e4-11e7-90ca-3f2ffa915b81 { StatusCode: 
200,
FunctionError: 'Unhandled',
Payload: '{"errorMessage":"RequestId: 3243f8d3-34e5-11e7-b0a2-df429a0d6565 
Process exited before completing request"}' }

在我们从 API 拉回信息的区域中，我们偶尔也会在 cloudwatch 中收到 lambda 错误消息，表示数据变量未定义，当它到达信息的第 11 天或第 12 天时也会发生这种情况，但在它还不到 10。这也让我们认为我们正在重载我们正在使用的 API。

据我了解，上述错误中的有效负载是我们在 event.variable 中传递给 lambda 的内容。每次我们尝试运行 30 天的信息时，我们都会在第 11-12 天收到此错误。此错误消息在与 RDS 数据库建立连接后直接出现。我基本上仍然是大多数这些东西的初学者，所以我不确定这个“未处理的有效负载”是否与 lambda 或 rds 有关，尽管我倾向于认为它与 RDS 有关。我以前从未见过这个错误，在研究它时似乎是一个相当广泛的错误。

如果是 RDS，此错误的原因可能是什么？我该如何解决？只是我的数据库太弱而无法处理负载吗？疯狂的是，即使我在调用下一个 lambda 之间设置了 60 秒的延迟，我仍然会收到此错误。但是，当我在控制台中将 lambda 设置为 60 秒触发器并在 30 分钟后手动打开和关闭它时，它运行良好。我不明白我在代码中设置 60 秒延迟以调用 lambda 的新实例和通过控制台设置 60 秒触发器之间的区别，当它们都每 60 秒触发一个新的 lambda 实例时.为什么一个工作完美而另一个给我上面的错误消息，唯一的区别是通过我的代码每 60 秒调用一次，而另一个通过 AWS Lambda 控制台每 60 秒调用一次。

目标是在通过 API-Gateway 中的 http 端点提交网页的表单时触发 lambda，将一条信息从其中一个表单传递到 lambda。来自 api-gateway 的触发工作，并且 lambda 工作到一个点，所以如果我可以让端点启用 60 秒触发器，并在 1800 秒或 30 分钟后将其关闭，我知道 100% 的事实它会功能完美。但是它一直困扰着我，我无法理解为什么当调用 lambda 的方式基本上在做同样的事情时它不起作用，而且我找不到该错误消息的原因。

Answer 1

我很确定我已经找到了问题的原因，以及为什么 60 秒的延迟对于尝试递归循环 AWS-lambda 函数永远不起作用。根据我的最佳解释，当您以编程方式调用 lambda 时，默认情况下，它设置为“同步模式”。假设您有 2 个 AWS-Lambda 函数。您从 lambda 1 调用 lambda 2。在 Lambda 2 完成之前，Lambda 1 不会认为自己已完成。如果 lambda 2 调用第三个 lambda，它将启动一个注定要失败的链。最重要的是，如果调用的 lambda 没有在 2 分钟标记处完成，它将尝试再次运行它，然后在 2 分钟后，第三次运行。

所以我运行它的方式基本上是引起连锁反应。越往下走，链越长，导致越来越多的 lambdas 达到 2 分钟和 4 分钟的标记，导致同一天的条目在数据库中多次上传，导致与 RDS 的连接泛滥以及我正在使用的 API，并最终导致所有 lambda 达到 5 分钟超时。

我们找到的解决方案是通过 AWS API-Gateway 的 http 端点调用它。它调用 lambda 并继续运行。当我们尝试这样做时，我们的倒计时开始了，30 天的信息在几分钟内就完成了。

另一方面，我知道有一种方法可以将您以编程方式调用的 lambda 设置为“异步模式”。我从未使用过它，我不确定它是否调用函数并继续运行，就像我最初认为我最初的想法正在做的那样，或者它是否像同步模式一样等待，即它调用的 lambda 必须完成在它认为自己完成之前。