Kinesis 数据流不是实时的吗？

Question

有一个被 Kinesis 流消息触发的函数（serverless.yml）：

functions:
  kinesis-handler:
    handler: kinesis-handler.handle
    events:
      - stream:
          type: kinesis
          arn:
            Fn::Join:
              - ':'
              - - arn
                - aws
                - kinesis
                - Ref: AWS::Region
                - Ref: AWS::AccountId
                - stream/intercom-stream
          startingPosition: LATEST
          batchSize: 100
          enabled: true

函数最终会被触发（在消息发送后2-5秒），但不是立即触发。这是有意设计的吗？我可以认为Kinesis数据流对于（近乎）实时事件驱动架构不太合适吗？

当触发器是Kinesis流时，实际上是什么触发了Lambda函数？看起来只有每1-2秒的后台定期轮询，如果在流中发现新消息，则会触发Lambda。

- Maxim Suponya

---

我也注意到了同样的行为，对于我的用例来说几秒钟的延迟还好，但我看到这对很多期望实时的人来说是一个问题。 - dege

Answer 1

你将批处理大小设置为100，这告诉 Lambda 在调用函数之前读取 100 条记录。与 batch 相关的设置有两个。

- 批处理大小：每批从数据流中读取的记录数，最多可达到 10,000 条。只要事件的总大小没有超过同步调用的负载限制（6 MB），Lambda 就会在单个调用中将整个批次的所有记录传递给函数。 - 批处理窗口：指定在调用函数之前收集记录的最大时间，以秒为单位。

在调用函数之前，Lambda 会继续从流中读取记录，直到它收集到完整的批次或批处理窗口过期为止。

我还没有对这两个设置进行性能测试，但我会先将大小设置为 1，将窗口设置为 0。然而，启动大量的 Lambda 可能会产生副作用，但它应该可以提供最小的延迟。

- WaltDe

---

这似乎是两个关键设置，但将它们更改为1和0似乎对调用延迟没有任何影响。影响的是传入消息的速率...发送消息之间的间隔越短，Lambda接收它们的间隔就越短。但它似乎总是落后1步.. - Maxim Suponya