Azure Functions事件中心触发器绑定

Question

关于在物联网场景中使用EventHub的Azure功能的使用,只有几个问题.

• EventHub有分区.通常,来自特定设备的消息将转到同一分区.如何在EventHub分区中分布Azure功能的实例？它是基于性能的吗？如果Azure功能的一个实例设法处理来自所有分区的事件,那么它就足够了,否则每个EventHub分区最终会有一个Azure功能实例？
• 读取偏移怎么样？这种绑定是否以某种方式记录它停止读取事件流的位置？我认为这些功能是无国籍的,在这里我们有一些状态.

谢谢

Answer 1

Event Hub-Triggered Function的每个实例仅由1个EventProcessorHost(EPH)实例支持.事件中心确保只有1个EPH可以在给定分区上获得租约.

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

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

首次启用函数时,只有1个函数实例.让我们调用这个Function实例Function_0. Function_0将有1个EPH,可以在所有10个分区上获得租约.让这个EPH称为EPH_0,它将开始从分区0-9读取事件.从现在开始,将发生以下情况之一:

1. 只需要1个Function实例 - 在Azure Functions的扩展逻辑启动之前,Function_0能够处理所有1000个.因此,所有1000条消息都由Function_0处理.

2. 再添加1个函数实例 - Azure Functions的缩放逻辑确定Function_0看起来很迟钝,因此创建了一个新的实例 Function_1,从而生成EPH_1.事件中心检测到新的EPH实例正在尝试读取消息.事件中心将开始跨EPH实例对分区进行负载均衡,例如,分区0-4分配给EPH_0,分区5-9分配给EPH_1.
   
   如果所有Function执行成功且没有错误,则EPH_0和 EPH_1检查点都成功完成,并处理所有1000条消息.当检查指向成功时,永远不应再次检索所有1000条消息.

3. 添加N个更多函数实例 - Azure Functions的缩放逻辑确定Function_0和Function_1仍然缓慢,并将再次为Function_2 ... N重复工作流2 ,其中N> 9.Event Hub将在Function_0 ... 9实例之间对分区进行负载平衡.
   
   Azure Functions的当前扩展逻辑的独特之处在于N >(分区数).这样做是为了确保总是有EPH的实例可以快速获得对分区的锁定.作为客户,您只需为您的Function实例执行时使用的资源付费,但您不需要为此过度配置付费.

对问题2的回答: EPH使用检查指向机制来标记最后已知的成功读取消息.可以将EventHub-Triggered功能设置为一次处理1条消息或一批消息.您选择的选项需要考虑以下事项:

1.消息处理速度 - 一次处理消息而不是一次处理单个消息是加快Azure功能工作流程跟上事件中心中传入消息的能力的因素之一.

2.重复容差 -如果由于功能代码中的错误/(2017年8月24日更新)超时/分区最少丢失导致检查指向失败,那么获得该分区租约的下一个EPH将开始从最后一个检索消息已知的检查站.Event Hub保证至少一次交付但不是最多一次交付.Azure Functions不会尝试更改该行为.如果没有重复消息是优先事项,那么您需要在工作流程中缓解它.因此,当检查指向失败时,如果您的功能正在批处理级别处理消息,则需要管理更多重复消息.