AWS 说如果您将 X-Amz-Invocation-Type 标头设置为 Event 是可能的,但几个月前我遇到了同样的必要性,这对我不起作用,所以我不确定情况是否仍然如此,或者如果只是我配置错误的话。也许你当时错过了和我一样的东西:我没有像文档建议的那样在集成请求上添加 InvocationType 标头,所以这很可能是你的情况,但我仍然不能保证它有效)
documentation 说:
在 API Gateway 控制台中配置 Lambda 异步调用
在集成请求中,添加 X-Amz-Invocation-Type 标头。
在方法请求中,添加一个 InvocationType 标头并将其映射到
集成请求中的 X-Amz-Invocation-Type 标头具有
'Event' 的静态值或
方法.request.header.InvocationType。对于后者,客户必须
在向
API 方法。
如果这可行,那么您就可以开始了。
然而,我当时所做的是创建一个中间 Lambda,它实际上充当了实际 Lambda 的代理。
有很多选项可以异步执行您的函数,但无论如何您都需要两个 Lambda 函数。
一种选择是通过 API Gateway 调用的函数异步调用另一个函数(它将实际执行您想要的任务)。
const params = {
FunctionName: 'YOUR_FUNCTIONS_NAME',
InvocationType: 'Event',
Payload: JSON.parse(event.body) // this is the event coming from API Gateway
};
await lambda.invoke(params).promise(); // await here is only going to wait for the HTTP request to be successful. Once the 2nd Lambda is invoked, it will return immediately
另一种选择是将消息放入 SQS 并配置触发器,以便在 SQS 队列中有新消息时调用您的 Lambda。 SNS 通知也是如此。
其他选项包括 Kinesis、DynamoDB Streams 等,但想法是一样的:通过 API Gateway 调用的函数只能是另一个 Lambda 的代理。这个代理将如何工作(向 SQS、SNS 发送消息,直接异步调用其他函数等)并不重要,重要的是绕过 API Gateway 的 30 秒请求限制的概念。