哪些 Azure .NET SDK EventHubClient 实例方法是线程安全的? [英] What Azure .NET SDK EventHubClient instance methods are threadsafe?

问题描述

我正在编写代码，用于将来自多个线程的消息发布到 Azure 事件中心 在 C# 中使用 EventHubClient.EventHubClient 的文档包含相当标准的样板.

I'm writing code that will be publishing messages from multiple threads to an Azure Event Hub in C# using the EventHubClient. The documentation for EventHubClient contains the fairly standard boiler plate.

这种类型的任何公共静态(在 Visual Basic 中共享)成员都是线程安全.不保证任何实例成员都是线程安全."

"Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

四个 发送方法我最愿意希望是线程安全的.如果我相信发送方法不是线程安全的，那么每次我希望发送到消息时，我最终都会创建一个新的 EventHubClient 实例.由于底层 tcp 连接是显然，除非采取措施这可能不会有太多的开销.分区发件人也会出现类似问题尽管考虑到有一种异步方法可以创建一个，但他们很可能拥有自己的 AMQP 连接.

There is no additional documentation as to thread safety in any of the four send methods I would most expect to be thread safe. Were I to believe that the send methods are not threadsafe then I would end up creating a new EventHubClient instance each time I wished to send to a message. Since the underlying tcp connection is apparently reused unless steps are taken this may not have too much overhead. Similar issues arise with partitioned senders though given that there is an async method to create one, they might well have their own AMQP connection.

尽管有文档说明，EventHubClient 线程的一些实例方法(如果不是全部)是否安全?

Are some, if not all, instance methods of EventHubClient thread safe despite the documentation?

对于任何 Azure 人员，是否有可能在文档中对此进行澄清?这种文档问题(假设它似乎是错误的)似乎也影响 Azure Table，并且通常在MSDN 文档.关于 EventHub，这与 Kafka 和 AWS Kinesis 至少没有明确标记所有内容为不安全.我在 SDK 的开源部分没有找到 EventHub，所以无法检查自己.

And for any Azure folks would it be possible to have this clarified in the documentation? This sort of documentation issue (assuming it is wrong as seems likely) appears to affect Azure Table as well and is generally common within the MSDN docs. With regards to EventHub this is in contrast to the clear thread safety statement of Kafka and AWS Kinesis at least does not explicitly label everything as unsafe. I did not find EventHubs in the open source portion of the SDK so could not check myself.

推荐答案

TLDR:

1. .NET SDK 中的所有关键运行时操作(也称为数据平面)都是线程安全的.
2. 创建一次EventHubClient 对象并重复使用

1. All critical runtime operations (aka data-plane) in the .NET SDK are thread-safe.
2. Create EventHubClient object once and re-use

故事

ServiceBus SDK 公开了两种模式来创建发送者:

ServiceBus SDK exposes two patterns to create senders:

1. 基本
2. 高级

对于基本版本 - 开发人员将直接使用 EventHubClient.CreateFromConnectionString() API 而不必担心管理 MessagingFactory 对象(连接 gu 的).SDK 将处理在所有 EventHubClient 实例中重复使用 MessagingFactory 只要 connection string 相同 - 所有键和值的文字匹配 - 是在 SDK 中完成此重用.

For Basic version - developer will directly use EventHubClient.CreateFromConnectionString() API and doesn't worry about managing MessagingFactory objects (connection gu's). SDK will handle reusing the MessagingFactory across all EventHubClient instances as long as the connection string is same - a literal match of all keys and values - is done in the SDK for this reuse.

对于需要在连接级别进行更多控制的高级开发人员，SB SDK 提供了 MessagingFactory.CreateFromConnectionString() 并且可以从该开发人员创建 EventHubClient 实例.

For an Advanced developer who will need a bit more control at connection level, SB SDK provides MessagingFactory.CreateFromConnectionString() and from this developer can create the EventHubClient instance.

EventHubClient 的所有实例方法 - 发送到 EventHubs 都是严格线程安全的.一般来说，所有数据平面操作都是...但是，在从 EventHub 读取时，API 已针对此模式进行了优化.<代码>而(真){var events = eventHubPartitionReceiver.receive(100);processMyEvents(事件)；}因此，例如:EventHubReceiver.RuntimeInformation 之类的属性 - 在每次 receive 调用后填充，无需任何同步.因此，即使实际的 receive API 是线程安全的 - 对 RuntimeInformation 的后续调用不是 - 因为很少有人在一个实例上放置多个 receive 调用PartitionReceiver.

All instance methods of EventHubClient - to send to EventHubs are strictly thread-safe. In general, all data-plane operations are... However, while reading from EventHubs, API is optimized for, this pattern. while(true) { var events = eventHubPartitionReceiver.receive(100); processMyEvents(events); } So, for ex: properties like, EventHubReceiver.RuntimeInformation - is populated after every receive call without any synchronization. So, even though the actual receive API is thread-safe - the subsequent call to RuntimeInformation isn't - as it is rare for anyone to park multiple receive calls on an instance of PartitionReceiver.

在每个组件中创建一个 EventHubClient 的新实例以开始发送消息是默认模式 - ServiceBus SDK 将负责重用底层 MessagingFactory - 它重用相同的物理套接字(如果连接字符串相同).

Creating a new instance of EventHubClient in each component to start send messages is the default pattern - and the ServiceBus SDK will take care of reusing the underlying MessagingFactory - which reuses the same physical socket (if the connection string is same).

如果您正在寻找真正的高吞吐量场景，那么您应该设计一个策略来创建多个 MessagingFactory 对象，然后每个创建一个 EventHubClient.但是 - 在尝试之前，请确保您已经在门户上增加了 EventHub 的吞吐量单位，因为默认设置仅为 1 MBPS - 所有 16 个分区的累积.

If you are looking for real high throughput scenarios then you should design a strategy to create multiple MessagingFactory objects and then Create an EventHubClient each. However - make sure that you have already increased the Thruput units for your EventHub on the Portal before trying this as the default is just 1 MBPS - cumulative of all 16 partitions.

此外，如果您使用的发送模式是分区发件人 - 它们也将使用相同的底层 MessagingFactory - 如果您从同一个 eventHubClient(.CreatePartitionedSender()) 实例创建所有发件人.

Also, if the Send pattern you are using is Partitioned Senders - they all will also use the same underlying MessagingFactory - if you create all Senders from the same eventHubClient(.CreatePartitionedSender()) instance.

这篇关于哪些 Azure .NET SDK EventHubClient 实例方法是线程安全的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！