Azure.Messaging.EventHubs EventProcessorClient - 在关闭/重新启动时写入检查点

Question

我们正在使用EventProcessorClient类从事件中心的所有分区读取消息。

为了增强检查点写入，我们持有一个计数器，并在处理 ProcessEventAsync 中的多条消息后执行检查点操作。而不是在每一个之后。

当服务重新启动或部署时，我们注意到由于检查点在停止之前没有更新，我们重新读取了之前处理的消息。

This blog提到了频繁检查点的模式，并建议在 OnPartitionProcessingStopped 内执行最后一个检查点实现EventProcessor<TPartition>时.

但是，当使用EventProcessorClient时，实现被包装并且只有 PartitionClosingAsync事件被调用，该事件没有更新检查点所需的详细信息。

在使用 EventProcessorClient 时关闭时，有没有办法将检查点更新到最新的检查点？

Answer 1

有几种不同的方法可以做到这一点，但复杂程度各不相同。然而，在大多数情况下，关闭时的检查点不太可能达到您希望的效果。对于感兴趣的人来说，上下文位于下面的“负载平衡详细信息”中。

操作方法:一种简单的方法

最直接的方法是保留类级成员中每个分区处理的最后一个事件的 ProcessEventArgs 来执行此操作。

这样，您仍然很可能会遇到详细信息中描述的决斗所有者场景。

操作方法:更复杂、内存更少、挑战相同

如果扩展 EventProcessorClient，您可以仅保留每个分区最后处理的偏移量，并使用它来调用 protected UpdateCheckpointAsync处理器上的方法。这可以为您节省一些空间，因为您只保留一个 long 而不是与事件参数关联的状态。

这样，您仍然很可能会遇到详细信息中描述的决斗所有者场景。

操作方法:更加复杂、更加高效且没有重叠

要使这一点有意义，您必须拥有稳定数量的处理器 - 没有动态扩展。

检查点采用与上述相同的方法 - 您将扩展处理器客户端并使用偏移量来调用 UpdateCheckpointAsync，如上所述。

为了避免所有权更改和倒回，您将为处理器分配一组静态分区并绕过负载平衡。该方法在 Static partition assignment sample 中进行了描述。 ，可以在扩展 EventProcessorClient 时应用。

这样一来，您就不会出现重叠所有者的情况。由于分区是静态分配的，因此您知道该节点将是唯一处理它们的节点。

这里的权衡是你失去了负载平衡和动态分配。如果节点崩溃或失去网络连接，则没有人会处理它拥有的分区集。这通常在有协调器监视节点并确保它们健康的主机环境中运行良好。

负载均衡详细信息

当分区改变所有者时，这不是有序的交接；处理器不会协调以确保旧所有者在新所有者开始读取之前已停止。因此，通常会存在一段重叠时期，旧所有者在内存中拥有一组事件，并且在尝试读取下一批事件之前不会意识到新所有者已接管。

在此期间，新旧所有者都在处理来自同一分区的事件。两者都可能发出检查点。如果旧所有者在该分区的处理停止时发出检查点，则很有可能它将检查点位置回滚到比当前所有者写入的更早的点。如果在新所有者发出检查点之前所有权再次发生变化，这会导致更大的倒带。

我们通常建议您在每次扩展处理器数量或部署/重新启动节点时都希望倒回一个检查点。这是设计检查点策略时需要考虑的事情。