我们在流量高峰期间将事件发送到 EventHub 时遇到了很多此类异常:
“无法将事件发送到 EventHub。异常:Microsoft.ServiceBus.Messaging.MessagingException:服务器无法处理请求；请重试该操作。如果问题仍然存在，请联系您的服务总线管理员并提供跟踪信息ID。” 或者 “无法将事件发送到 EventHub。异常:System.TimeoutException:操作未在分配的时间内完成”
你可以在这里清楚地看到它:
如您所见，当传入消息超过 400K 事件/小时(或约 270 MB/小时)时，我们会遇到大量内部错误、服务器繁忙错误、请求失败。这不仅仅是一个暂时的问题。它显然与吞吐量相关。
我们的 EH 有 32 个分区，消息保留 7 天，并分配了 5 个吞吐量单位。 OperationTimeout 设置为 5 分钟，我们使用默认的 RetryPolicy。
这里还有什么我们需要调整的吗？我们非常关心 EH 的可扩展性。
谢谢
最佳答案
可以使用有效的分区分布策略来实现发送吞吐量调整。没有任何一个旋钮可以做到这一点。以下是您设计高吞吐量场景所需的基本信息。
1) 让我们从命名空间开始:吞吐量单位(又名 TU)在命名空间级别配置。请。请记住，应用配置的 TU - 该命名空间下所有 EventHub 的聚合。如果您的命名空间上有 5 个 TU，并且其下有 5 个 eventhub - 它将被分配给所有 5 个 eventhub。
2) 现在让我们看看 EventHub 级别:如果 EventHub 分配了 5 个 TU 并且有 32 个分区 - 没有一个分区可以使用全部 5 个 TU。对于前。如果您尝试将 5TU 数据发送到 1 个分区，并将“零”数据发送到所有其他 31 个分区 - 这是不可能的。每个分区应规划的最大值为 1 TU。一般来说，您需要确保数据均匀分布在所有分区上。 EventHubs 支持 3 种类型的发送 - 这为用户提供了对分区分布的不同级别的控制:
- EventHubClient.Send(EventDataWithoutPartitionKey) -> 如果您使用此 API 发送 - eventhub 将负责在所有分区之间均匀分布数据。 EventHubs服务网关会将数据循环发送到所有分区。当特定分区出现故障时，网关会自动检测并确保客户端不会受到任何影响。 这是最推荐的发送到 EventHub 的方式。
- EventHubClient.Send(EventDataWithPartitionKey) -> 如果您使用此 API 发送到 EventHubs，partitionKey 将确定数据的分布。 PartitionKey 用于将 EventData 哈希到适当的分区(哈希算法是 Microsoft 专有而非共享)。通常，需要关联一组消息的用户会使用这种发送变体。
- EventHubSender.Send(EventData) -> 在此变体中，Sender 已附加到分区。因此，这可以让客户端完全控制跨分区的分发。
要测量您当前的数据分布 - 使用 EventHubClient.GetPartitionRuntimeInfo用于估计哪个分区过载的 API。 BeginSequenceNumber 和 LastEnqueuedSequenceNumber 之间的差异应该可以给出该分区与其他分区负载相比的估计值。
3) 最后但并非最不重要的 - 您可以使用 SendBatch API 在发送操作级别调整性能(而不是吞吐量)。 1 TU 可以购买最大 1000 条消息/秒或 1MBPS - 您将受到先达到的限制 - 这是无法更改的。 如果您的消息很小 - 比如说 100 个字节，并且您每秒只能发送 1000 条消息(根据 TU 限制) - 您将首先达到每秒 1000 个事件的限制。然而，总体使用SendBatch API - 您可以批量处理 10 个 100 字节的消息，并以相同的速率推送 - 1000 条消息/秒，只需 100 个 API 调用，并改善系统的端到端延迟(因为它还有助于服务有效地持久化消息)。请记住，这里唯一的限制是最大值。可以发送的消息大小 - 256 kb(如果您使用 SendBatch API，则此限制将适用于您的 BatchSize)。
鉴于这种背景，就您而言: - 有 32 个分区和 5 个 TU - 我真的会仔细检查分区分配策略。
关于azure - 高吞吐量发送到 EventHubs 导致 MessagingException/TimeoutException/服务器无法处理请求错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33661538/