当有多个订阅者时，Azure 事件网格如何处理故障？答案

【问题标题】：How does Azure Event Grid handle failure when there are multiple subscribers?当有多个订阅者时，Azure 事件网格如何处理故障？
【发布时间】：2019-01-24 22:35:42
【问题描述】：

Event Grid 的文档指出它内置了 delivery and retry mechanism，并给出了一个示例来说明什么是成功或失败的尝试。文档非常清楚地说明了单个事件处理程序会发生什么。

我的问题是，如果有多个事件处理程序，而只有一个处理程序未能接收到事件，会发生什么？是仅针对该处理程序重试事件，还是所有处理程序都会看到重试？

【问题讨论】：

我只能假设，如果事件无法传递给任何个订阅者，那么它将是死信。话虽如此，最好在文档中提出这个问题。我做了here。
谢谢肖恩。我的问题实际上是关于重新传递，以及消息是重新传递给所有订阅者还是只传递给失败的订阅者，但死信也是一个很好的问题。我会将其添加到 GitHub 问题中。与此同时，我不确定是关闭这个问题还是让它保持打开状态
保持打开状态。 EG团队或您自己将回答。无论哪种方式，人们都会找到答案。
AEG 事件模型使用扇出模式将事件消息传递给订阅的处理程序。每个风扇输出的这种逻辑连接由订阅描述，它们彼此完全透明并且松散地解耦。此扇出模式中每个事件传递的行为基于它们的订阅，例如重试、死信、过滤等。注意，根据订阅者端点类型，我们可以轻松更改默认传递模式，例如 PushWithAck到 Pull 模式（异步），例如：存储队列和 HybridConnection
出于测试目的（例如您的问题），您可以使用测试工具codeproject.com/Articles/1254463/Azure-Event-Grid-Tester 在哪里可以模拟您的情况，例如：自定义主题 + 存储队列订阅者 + HybridConnection 订阅者出现错误(503) 交付模拟。

标签： azure-eventgrid

【解决方案1】：

基本上，Azure 事件网格事件 Pub/Sub 模型可以处理两种消息传递/中介模式，例如 Fan-In 模式和 Fan-Out（广播）模式。以下屏幕 sn-ps 显示了它们的区别：

Event Source 和 Event Sink 之间的逻辑连接由 Subscription 描述，它基本上是 Pub/Sub 模型的元数据工件。每个逻辑连接（由 Subscription 表示）都是独立的，并且与其他连接松散地解耦。换句话说，每个订阅者在这个 Pub/Sub 模型中只能处理一个逻辑连接，例如一个事件源。

您的问题与扇出（广播）模式有关，其中事件兴趣是使用 PushWithAck 交付模式向多个订阅者广播。此扇出模式中的每个订阅都有自己的“消息状态传递机器”，由订阅者声明，例如重试选项、死信、过滤等。

换句话说，向订阅者的事件传递是基于他们的订阅以透明的方式并行处理，彼此之间没有任何依赖关系。请注意，订阅者没有关于谁、在哪里、如何等将事件传递给其他人的任何信息，因此每个订阅者只能看到自己的传递状态，例如 Aeg-Delivery 的值-Count 显示状态机的重试计数器。

因此，在向多个订阅者之一传递事件失败的情况下，启用的重试过程仅针对该订阅者执行。

【讨论】：

谢谢罗曼。我没有意识到死信是每个订阅者的选项，我认为它是每个主题的，所以这解释了这一切如何按预期工作

【解决方案2】：

正如 Roman 所解释的，每个端点都是独立处理的。如果一个事件处理程序失败，它将在不影响其他事件处理程序的情况下重试，当然，如果该特定端点继续失败，它最终将被死信（假设已在事件订阅上配置死信）或丢弃。

【讨论】：

【解决方案3】：

在事件网格中进行事件发布时，来自自定义事件网格主题或系统事件网格主题（例如服务总线命名空间）的事件将转发到使用它们配置的事件网格订阅。然后将事件发送到配置了事件网格订阅的端点。

只要事件传递到终结点失败，就会根据配置的重试策略重试。如果重试次数超过配置的重试策略，如果配置为死信目标，则事件将存储在存储帐户 blob 中，否则事件将丢失。

默认情况下，事件网格会使所有未在 24 小时内交付的事件过期。您可以在创建事件订阅时自定义重试策略。您提供最大传递尝试次数（默认为 30）和事件生存时间（默认为 1440 分钟）。

当有多个订阅者（事件网格订阅）到同一个事件网格主题时，仅对事件传递失败的事件网格订阅进行重试。

请参阅 Event Grid message delivery and retry 了解有关重试策略的更多信息。

【讨论】：