来自 API 网关的 Lambda VS kinesis Streams

Lambda from API gateway VS kinesis Streams

背景

我正在研究 AWS 运动,API 网关。

我知道,每当请求到达 API 网关时,我都可以将数据转发到流中,或者我可以选择触发 lambda(这将进行一些处理)。

思考与疑问

所以,我的想法是,如果我可以直接从 API 网关触发一个 lambda(当请求到达时,它是实时的),拥有运动流的优势是什么(用于实时数据处理)?

我可以删除流并直接从 API 网关触发 lambda(甚至为不同的任务创建多个 APIs)

对这种情况有什么想法!

这取决于客户端访问的频率和您的 lambda 函数的时间长度。

lambda 函数的并发执行数限制为 100。当 lambda 被限制时,API Gateway 和 Kinesis stream 的重试方式不同。

参见https://docs.aws.amazon.com/lambda/latest/dg/concurrent-executions.html

您可能想要检查请求率的估计值。

此外,请记住 Kinesis 流保证数据到达分片的顺序。

您使用的解决方案实际上取决于您正在处理的数据以及您希望如何处理这些数据。有关场景的数据和结果的更多信息可以缩小 AWS 的适用范围。这是 3 个选项的简化:

  1. Kinesis Streams 基本上提供了对大量数据的时移 window。它负责将数据存储足够长的时间,以便您可以挑选相关数据或执行聚合。您对数据的分析可以存储在数据库中。当不需要存储所有传入的数据且成本高昂时,Kinesis Streams 是一个不错的选择。

  2. Kinesis Firehose 提供了一个端点,供您将数据发送到 S3、Redshift 或 Elastic Search(或某些组合)。然后,您可以对该存储的数据执行分析。如果您只想将原始数据保存在数据库中供以后处理,这是一个不错的选择。但是,您需要为该数据的存储付费。如果您只需要数据的一个子集或分析结果,那将是昂贵的。

  3. API Lambda 网关允许您实时处理数据。 lambda 可以对数据做任何您想做的事情,您可以使用此解决方案获得最大的灵活性。但是您必须单独处理每个请求,而 Kinesis Streams 允许您分析一批数据。