c# - 是什么导致 Azure 事件中心 ReceiverDisconnectedException/LeaseLostException？

Question

我正在使用 EventProcessorHost 和 IEventProcessor 类(称为:MyEventProcessor)从 EventHub 接收事件。我通过在两台服务器上运行我的 EPH 并将它们扩展到两台服务器，并让它们使用相同的 ConsumerGroup 连接到集线器，但使用唯一的主机名(使用机器名称)。

问题是:在白天/黑夜的随机时间，应用程序会记录以下内容:

Exception information: 
Exception type: ReceiverDisconnectedException 
Exception message: New receiver with higher epoch of '186' is created hence current receiver with epoch '186' is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
  at Microsoft.ServiceBus.Common.ExceptionDispatcher.Throw(Exception exception)
  at Microsoft.ServiceBus.Common.Parallel.TaskHelpers.EndAsyncResult(IAsyncResult asyncResult)
  at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result)

此异常与 LeaseLostException 同时发生，当它尝试检查点时从 MyEventProcessor 的 CloseAsync 方法抛出。 (大概是因为 ReceiverDisconnectedException 正在调用 Close？)

我认为这是由于事件中心在扩展到多台机器时的自动租用管理而发生的。但我想知道我是否需要做一些不同的事情来使它更干净地工作并避免这些异常？例如:有时代的东西？

Answer 1

TLDR : 这种行为绝对正常。
为什么租赁管理不能顺畅无异常 :让开发人员更好地控制情况。

真正的长篇大论——从基础知识开始EventProcessorhost (在此 EPH - 与 __consumer_offset topic 为 Kafka Consumers 所做的非常相似 - 分区所有权和检查点存储)由 Microsoft Azure EventHubs 编写团队自己- 翻译所有EventHubs partition receiver Gu变成一个简单的onReceive(Events)打回来。
EPH用于在读取高吞吐量分区流(如 EventHubs)时解决 2 个一般的、主要的、众所周知的问题。 :

容错接收管道 - 例如:问题的更简单版本 - 如果主机运行 PartitionReceiver死亡并返回 - 它需要从离开的地方恢复处理。记住最后一次成功处理 EventData , EPH使用 blob提供给 EPH存储检查点的构造函数 - 当用户调用时 context.CheckpointAsync() .最终，当主机进程终止时(例如:突然重启或遇到硬件故障并且永不/恢复) - 任何 EPH实例可以拿起这个任务并从那个 Checkpoint 继续.

跨 EPH 平衡/分布分区实例 - 假设，如果有 10 个分区和 2 EPH实例处理来自这 10 个分区的事件 - 我们需要一种方法来跨实例划分分区( PartitionManager 库的 EPH 组件就是这样做的)。我们使用 Azure Storage - Blob LeaseManagement-feature 来实现这一点。截至版本 2.2.10 - 为了简化问题，EPH假设 所有分区均等加载 .

有了这个，让我们试着看看发生了什么:
所以，首先，在上述 10 的例子中事件中心分区和 2 EPH实例处理其中的事件:

让我们说第一个 EPH实例 - EPH1开始，首先，单独和启动的一部分，它为所有 10 个分区创建接收器并正在处理事件。在启动- EPH1将宣布它拥有所有这些10通过在 10 上获取租约进行分区代表这些的存储 blob 10事件中心分区(使用标准 nomenclature - EPH 在存储帐户中内部创建 - 从 StorageConnectionString 传递给 ctor )。租约是acquired for a set time ，之后是 EPH实例将失去此分区的所有权。

EPH1不断announces偶尔 - 它仍然拥有这些分区 - 通过 renewing在 blob 上租用。 renewal的频率以及其他有用的调整，可以使用 PartitionManagerOptions 执行

现在，让我们说，EPH2启动 - 并且您提供了相同的 AzureStorageAccount如 EPH1到 ctor的 EPH2以及。现在，它有 0要处理的分区。因此，要实现 EPH 之间的分区平衡实例，它将继续和 download所有列表leaseblobs其中有 owner 的映射至 partitionId .由此，它会STEAL租赁为其公平份额 partitions - 这是 5在我们的示例中，并会宣布该信息 lease blob .作为其中的一部分，EPH2读取 PartitionX 写入的最新检查点它想窃取租约并继续创建相应的 PartitionReceiver与 EPOCH与 Checkpoint 中的相同.

结果，EPH1将失去这 5 个的所有权 partitions并且会根据它所处的确切状态遇到不同的错误。

如果 EPH1实际上是在调用 PartitionReceiver.Receive()调用 - 同时 EPH2正在创建 PartitionReceiver在同一个接收器上 - EPH1会体验ReceiverDisconnectedException .这最终将调用 IEventProcessor.Close(CloseReason=LeaseLost) .请注意，如果接收到的消息较大或 PrefetchCount，则命中此特定异常的概率较高。更小——因为在这两种情况下，接收器都会执行更积极的 I/O。

如果 EPH1处于checkpointing的状态lease或 renewing lease , 而 EPH2 stole租约，EventProcessorOptions.ExceptionReceived eventHandler 将用 leaselostException 发出信号(在 409 上有 leaseblob 冲突错误) - 最终也会调用 IEventProcess.Close(LeaseLost) .

为什么租赁管理不能顺畅无异常 :

为了让消费者保持简单和无错误，租约管理相关的异常可能已经被 EPH 吞掉了。并且根本没有通知用户代码。然而，我们意识到，抛出 LeaseLostException可以让客户在 IEventProcessor.ProcessEvents() 中发现有趣的错误回调 - 其症状是 - 频繁的分区移动

特定机器上的轻微网络中断 - 由于这个原因 EPH1失败 renew租赁并回来! - 想象一下，如果这台机器的 n/w 断断续续一天 - EPH实例将要播放 ping-pong与 Partitions !这台机器会不断地尝试从其他机器上窃取租约——这是合法的 EPH观点 - 但是，对于 EPH 的用户来说是一场灾难- 因为它完全干扰了加工管道。 EPH - 会准确地看到 ReceiverDisconnectedException ，当 n/w 重新出现在这个片状 m/c 上时!我们认为最好的也是唯一的方法是让开发人员闻到这一点!

或者一个简单的场景，比如在 ProcessEvents 中有一个错误逻辑 - 抛出未处理的异常，这些异常是致命的并导致整个过程 - 例如:中毒事件。这个分区会移动很多。

客户，在与 EPH 相同的存储帐户上执行写入/删除操作也在使用 - 错误地(如自动清理脚本)等。

最后但并非最不重要的 - 我们从不希望发生这种情况 - 说 5 分钟 outage在 Azure dc 上，其中一个特定的 EventHub.Partition位于 - 比如说 n/w 事件。分区将在 EPH 之间移动实例。

基本上，在大多数情况下，这会很棘手 - 我们要检测差异。在这些情况和由于平衡而导致的合法租约丢失之间，我们希望将这些情况的控制权委托(delegate)给开发人员。

more on Event Hubs...