通过 DynamoDB 流的 Lambda 触发器延迟答案

【问题标题】：Lambda trigger lag through DynamoDB streams通过 DynamoDB 流的 Lambda 触发器延迟
【发布时间】：2019-11-08 22:02:38
【问题描述】：

假设：

让我们假设数据插入 DynamoDB 的速度非常快。

上下文：

在 DynamoDB 表上启用了流，这将触发 lambda。 lambda 读取流式记录并在弹性搜索中索引记录。

问题陈述：

记录插入 DynamoDB 的时间与通过流式记录触发 lambda 的时间之间存在延迟。这种延迟或延迟不断增加，并且与插入 dynamoDB 的数据量成正比。

如何找到滞后在哪里？是不是流没有立即触发 lambda？或者因为有大量的发电机写入数据流受到阻碍？或者是否有任何限制 lambda 在给定的秒内不能被击中一定次数？

我不明白问题出在哪里，因为我什至看不到当前流是否仍然包含记录，或者流中的记录是否已经交付但 lambda 触发器是滞后的？

延迟示例：我们昨天写了很多，今天我们看到这些记录达到了 lambda！难以置信的延迟！ :)

有什么建议吗？

【问题讨论】：

您在查看 lambda 的监控选项卡吗？您应该看到 IteratorAge、执行时间、并发调用。平均执行时间是多少？
有高达 4.6k 的并发调用，但是是的，这些峰值并不一致，但是是的，我看到了足够的峰值，范围从 800 到 4.6k。 ***** 迭代器年龄从 43M 到 110M **** 平均持续时间达到 30k 到 300k
执行时间是问题。首先，您可以尝试增加 lambda 的内存，但您还需要寻找其他方法来降低执行时间。还要确保您没有包含大量项目的分区。
我想我想通了。 lambda 的触发器数量很大，并且 iteratorAge 非常高。我们需要优化 lambda，以便它可供所有即将到来的人使用

【解决方案1】：

来自Lambda Documentation

对于处理 Kinesis 或 DynamoDB 流的 Lambda 函数，分片数是并发单位。如果您的流有 100 活跃分片，最多有 100 次 Lambda 函数调用同时运行。这是因为 Lambda 处理每个分片的事件顺序。

创建分片的逻辑不会暴露给最终用户。但这取决于你的 RSU and WSUs. 但是增加太多会花钱。

最重要的是，并发 lambda par 账户是有限制的。取决于您的运营区域（请参阅here）。

这里有一些你可以做的事情

【讨论】：

1.我的 PK 是 UUID 2。我什至不担心与 ES 的索引/连接数，因为我们索引到 ES 本身的那个 lambda 有很大的滞后。 3. 批量已从 100 增加到 1000！ 4. 我们使用 Python 3.7 5. 是的，不太可能！
从 100 增加到 1000 也会导致延迟，因为现在您的队列将等到它有 1000 条记录，这可能需要一些时间，因为您使用的是 uuid，因此这是一个坏主意
是真的吗？是不是要等到1000？如果有 1000 个或任何可用的，我希望它发送 1000 个。你说的是真的，那么我应该看到一个有 1000 条记录的流 lambda 事件。从来都不是这样
The number of records to read from a shard in each batch, up to 1,000. Lambda passes all of the records in the batch to the function in a single call, as long as the total size of the events doesn't exceed the payload limit for synchronous invocation (6 MB). 因此，您将达到 6mb 的限制而不是 1000，只需从 1000 减少到 1，看看您是否立即收到事件。
我明白你在说什么，但即使 batchSize 设置为 1000，在 lambda 事件中，我从未见过包含超过 5 个（最大）记录的事件。