Azure Functions 事件中心触发器绑定(bind)

Question

有几个关于在 IoT 场景中使用 Azure Functions 和 EventHub 的问题。

• EventHub 有分区。通常，来自特定设备的消息会发送到同一分区。 Azure Function 的实例如何跨 EventHub 分区分布？是根据表现来决定的吗？如果一个 Azure Function 实例能够处理来自所有分区的事件，那么就足够了，否则最终可能每个 EventHub 分区都有一个 Azure Function 实例？
• 读取偏移量怎么样？此绑定(bind)是否以某种方式记录了它停止读取事件流的位置？我认为这些函数应该是无状态的，而这里我们有一些状态。

谢谢

Answer 1

事件中心触发函数的每个实例仅由 1 个 EventProcessorHost(EPH) 实例支持。事件中心确保只有 1 个 EPH 可以在给定分区上获得租约。

问题 1 的回答:让我们用一个人为的例子来详细说明这一点。假设我们从 EventHub 的以下设置和假设开始:

1. 10 个分区。
2. 1000 个事件均匀分布在所有分区中 => 每个分区中有 100 条消息。

首次启用您的函数时，该函数只有 1 个实例。我们将此函数实例称为“Function_0”。 Function_0 将拥有 1 个 EPH，可成功获得所有 10 个分区的租约。将此 EPH 称为 EPH_0，它将开始从分区 0-9 读取事件。从此时开始，将会发生以下情况之一:

1. 仅需要 1 个函数实例 -Function_0 能够在 Azure Functions 的缩放逻辑启动之前处理所有 1000 个函数实例。因此，所有 1000 条消息均由 Function_0 处理。

2. 再添加 1 个 Function 实例 -Azure Functions 的缩放逻辑确定 Function_0 似乎运行缓慢，因此需要一个新实例Function_1 已创建，生成 EPH_1。事件中心检测到新的 EPH 实例正在尝试读取消息。事件中心将开始加载平衡 EPH 实例之间的分区，例如分区分区 0-4 分配给 EPH_0，分区 5-9 分配给 EPH_1。
   
   如果所有函数执行成功且没有错误，EPH_0 和EPH_1 检查点成功，所有 1000 条消息均已处理。当检查点成功时，所有 1000 条消息都不应再次检索。

3. 再添加 N 个函数实例 -Azure Functions 的缩放逻辑确定 Function_0 和 Function_1 仍然缓慢且将为 Function_2...N 再次重复工作流程 2，其中 N>9。事件中心将在 Function_0...9 实例之间对分区进行负载平衡。
   
   Azure Functions 当前的缩放逻辑的独特之处在于 N 是>(分区数)。这样做是为了确保总有 EPH 实例可供快速使用锁定分区。作为客户，您只需为 Function 实例执行时使用的资源付费，但无需为这种超额配置付费。

问题 2 的回答:EPH 使用检查点机制来标记最后已知的成功读取消息。 EventHub 触发函数可以设置为一次处理一条消息或一批消息。您选择的选项需要考虑以下因素:

<强>1。消息处理速度 - 批量处理消息而不是一次处理一条消息是加快 Azure Function 工作流程跟上传入消息速度的因素之一。事件中心中的消息。

<强>2。重复容忍 - 如果检查点由于 函数代码中的错误/ (2017 年 8 月 24 日更新)超时/分区丢失而失败，则下一个获得租约的 EPH该分区将开始从最后一个已知检查点检索消息。事件中心保证至少一次传送，但不保证最多一次传送。 Azure Functions 不会尝试更改该行为。如果优先考虑的是不存在重复消息，那么您将需要在工作流程中减轻它的影响。因此，当检查点失败时，如果您的函数正在批量处理消息，则需要管理更多重复消息。