azure-functions - Azure EventHub 和函数 LeaseLostException

Question

关于我们反复看到的以下异常，我们在消费计划 Function App 上看到了异常奇怪的行为:

• Microsoft.Azure.EventHubs.RecieverDisconnectedException(创建了具有更高纪元“2”的新接收器，因此具有纪元“1”的当前接收器正在断开连接。)
• System.Net.WebException(抛出“Microsoft.ServiceBus.Messaging.LeaseLostException”类型的异常。)

每当我们强调功能时，我们都会遇到这些异常，即在短时间内从 0 到 50,000 个事件，但它们与匹配我们的功能应用程序的 cloud_role Hook 。这让我相信这是一个主机错误。 .

阅读各种 doco，即(https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-features)，我认为我理解 EventHub 接收器是如何工作的[但老实说，我在字里行间阅读，因为它很不清楚]我的一个接收器依赖于一个消费者组来管理从 EventHub 分区(我正在使用其中的 32 个)读取的消息批处理。

我的假设是，在负载下，单个消费者组无法“应对”太多的功能实例，并且它只是重复地切换分区的租约......然而，在我的测试场景中，我删除了除了在事件中心之间中继消息之外，函数中的所有逻辑，即使 EventHub 上只有 4 个分区，错误仍然存​​在

为了看看是否在以后的版本中得到解决，我在 Functions v2 中模拟了完全相同的功能，并收到了我认为与 .net 核心等效的东西..

1. Microsoft.Azure.EventHubs.RecieverDisconnectedException(创建了具有更高纪元“2”的新接收器，因此具有纪元“1”的当前接收器正在断开连接。)
2. Microsoft.WindowsAzure.Storage.StorageException(指定的租用 ID 与 blob 的租用 ID 不匹配。)
3. System.ArgumentOutOfRangeException(忽略偏移量为 1184072/序列号为 1038 的过时检查点，因为...)

所以，有人可以吗

• 解释幕后实际上到底发生了什么
• 帮助我抑制这些，如果它们不是实际的“真实”错误，它们只是管理事物的主机...

这些异常真的很烦人，因为很难真正看到真正的未处理异常。

Answer 1

这些是虚假错误，是由于 Function App(主机进程)内的 Function 的动态扩展/缩减引起的，您可以忽略它们。

可以理解的是，它们出现在您的日志中这一事实令人担忧，我们已经开始了一些工作来抑制一些错误(参见 https://github.com/Azure/azure-webjobs-sdk/issues/1760 )。这是与版本 v1.0.11913 一起发布的您应该将它们视为警告。欢迎 file an issue如果它们仍然显示为错误。

有关为什么会出现这些异常的其他背景信息

让我们从一些关于 EventHub 缩放如何工作的初步知识开始，正如这篇文章中提到的:https://stackoverflow.com/a/42911842/6465830

<强>1。 Microsoft.ServiceBus.Messaging.LeaseLostException

每次横向扩展操作成功时，EventHub 都会在 (1..N) 组 EventProcessorHosts 中重新分配分区租约获得分区的租约，其中 N 是您的 EventHub 的分区数。例如，如果您仅从 Function_0 开始，并且它设法在所有 10 个分区上获取最少，当我们扩展到 Function_1 并且 EventHub 决定在两者之间平均分配消息函数，然后 Function_0 将失去对其中 5 个分区的租约。此行为解释了您看到的 Exception of type 'Microsoft.ServiceBus.Messaging.LeaseLostException' was throwed。

<强>2。 Microsoft.Azure.EventHubs.ReceiverDisconnectedException

此外，Azure Functions 还横向扩展到>N 个实例，所以会有一组N+1...M，其中，M 是无法在任何分区上获得租约的横向扩展实例的总数。这样做的副作用是总会有一个 EPH 准备好快速获取丢失的租约以保持管道运行。这解释了 具有更高历元“2”的新接收器已创建，因此具有历元“1”的当前接收器正在断开连接。 您看到的。同样，您仅在函数执行时才需要付费，因此这里存在一些超额配置这一事实不会影响您的计费。