Azure EventGrid 批处理延迟

Question

当使用 EventGrid 订阅 BlobCreated 事件，然后调用 Azure Function 来处理该批次时，EventGrid 需要等待多长时间才能交付该批次？

我想在 Azure 数据工厂从文件服务器复制 BlobCreated 事件后接收它们，但我不认为 ADF 可以保证所有 Blob 同时并行出现在 Blob 存储中，所以我提出的解决方案最后是在复制活动完成后从 ADF 调用我的 Azure 函数。

我在docs中找到了这条评论，这似乎回答了我的问题？

如果可用事件较少，事件网格不会延迟事件来创建批次。

我还读到here我的函数是按批处理数组中的每个元素调用的？这显然会破坏批处理的整个目的......

我可以选择哪些选项来避免使用 HTTP 触发器并从 ADF 调用它？

我考虑使用 StorageQueue 来存储 EventGrid 消息，然后在新的队列项上触发我的函数，然后等待一分钟直到队列填满，然后开始处理事件。这似乎确实有效，但是阅读每个请求 32 条消息，直到我有 1000 条消息要处理，感觉很慢......

我想不出更好的方法来做到这一点，直到我决定对于我们的特定用例来说，有一个由 ADF 调用的 HTTP 触发函数就足够了。队列解决方案将是理想的，因为使用 HTTP 触发器，我无法扩展到多个实例，否则可能会出现竞争条件，其中第二个实例正在读取和处理相同的 blob，但对于我们的用例来说，这似乎已经足够了。

谢谢

Answer 1

作为替代建议，您可以在复制活动日志文件上使用 blob 触发器函数，这将为每批记录调用该函数。

首先，您需要在复制活动设置中启用日志。

启用日志记录后，您可以在连接中提供存储链接服务。 根据您设置的所需详细信息将日志级别记录为Info。 接下来，记录模式为Besteffort，该模式记录批量记录的详细信息，然后给出存储路径。

复制活动完成后，在Json输出中 日志文件路径将会出现

或在您的存储帐户路径中，如下所示。

https://[your-blob-account].blob.core.windows.net/[logFilePath]/copyactivity-logs/[copy-activity-name]/[copy-activity-run-id]/[auto-generated-GUID].txt

这是日志文件的架构，您可以在函数中使用它来检查写入和跳过的文件。

接下来，您提供文件夹路径，直到复制活动名称

https://[your-blob-account].blob.core.windows.net/[logFilePath]/copyactivity-logs/[copy-activity-name] 创建azure blob触发功能时。

以下是您需要在函数逻辑中检查的内容。

如果您正在执行的操作与尚不存在的文件之间存在依赖关系，则跳过该过程，在下一个触发器中您可以处理它。
您以 csv 形式读取此日志文件，并根据您拥有的逻辑检查预期的文件是否已完成。

这样您就可以避免过多触发您的函数。