事件中心常见问题

命名空间是用于定义事件中心/Kafka 主题范围的容器。 命名空间充当容装多个事件中心/Kafka 主题的应用程序容器。

不是。 在部署后，如果没有部署新资源，则无法（例如）从标准层更改为高级层。

容量分配（吞吐量单位 (TU) 或处理单位 (PU)）在命名空间级别计费。 命名空间也与区域相关联。

在以下方案之一中，你可能想要创建一个新的命名空间，而不是使用现有命名空间：

• 需要与新区域关联的事件中心。
• 需要一个不同于当前订阅的事件中心。
• 需要具有不同容量分配的事件中心（也就是说，具有添加的事件中心的命名空间的容量需求将超过 40 TU 阈值）。

Azure 事件中心标准层提供的功能超出了基本层中提供的功能。 以下功能是标准层附带的：

• 更长的事件保留期
• 额外的代理连接，对于超出包含数量的部分将收取超额费用
• 多于单个使用者组
• 捕获
• Kafka 集成

有关定价层的详细信息，请参阅 事件中心定价详细信息。

在所有支持的 Azure 区域中都可使用 Azure 事件中心。 有关列表，请访问 Azure 区域页。

可以，但前提是所有事件中心都在同一个命名空间中。

事件中心标准层目前支持最长保留期为 7 天，而对于高级层，此限制为 90 天。 事件中心不应作为永久性的数据存储。 超过 24 小时的保持期适用于可轻松将事件流重播到相同系统中的方案。 例如，基于现有数据训练或验证新机器学习模型。 如果需要将消息保留七天以上，请启用事件中心的事件中心捕获功能，将数据从事件中心提取到所选的存储帐户或 Azure Data Lake 服务帐户。 启用捕获功能需要支付费用，具体因购买的吞吐量单位而异。

可以在存储帐户上配置已捕获数据的保留期。 Azure 存储的“生命周期管理”功能为常规用途 v2 和 blob 存储帐户提供了基于规则的丰富策略。 可使用该策略将数据转移到适当的访问层，或在数据的生命周期结束时使数据过期。 有关详细信息，请参阅管理 Azure Blob 存储生命周期。

事件中心向 Azure Monitor 提供详尽的指标，报告您的资源的状态。 它们还允许您不仅在命名空间级别，而且在实体级别评估事件中心服务的总体健康状况。 了解 Azure 事件中心提供哪些监视功能。

创建事件中心命名空间时，Azure 事件中心的标准层和高级层会在您选择的区域内存储并处理发布到其中的数据。 默认情况下，客户数据保留在该区域中。 为 Azure 事件中心命名空间设置异地灾难恢复时，会将元数据复制到你选择的次要区域。 因此，此服务会自动满足区域内数据驻留要求，包括信任中心内指定的要求。

可以使用哪些协议发送和接收事件？

生产者或发送者可以使用高级消息队列协议 (AMQP)、Kafka 或 HTTPS 协议将事件发送到事件中心。

使用者或接收者使用 AMQP 或 Kafka 从事件中心接收事件。 事件中心仅支持使用者通过拉取模型从中接收事件。 即使你使用事件处理程序来处理来自事件中心的事件，事件处理器内部也会使用拉取模型来接收来自事件中心的事件。

AMQP

可以使用 AMQP 1.0 协议向 Azure 事件中心发送事件以及从 Azure 事件中心接收事件。 AMQP 为发送和接收事件提供了可靠的、高性能的、安全的通信。 可以将其用于高性能的和实时的流式处理，大多数 Azure 事件中心 SDK 都支持它。

HTTPS/REST API

只能使用 HTTP POST 请求将事件发送到事件中心。 事件中心不支持通过 HTTPS 接收事件。 它适用于无法建立直接 TCP 连接的轻型客户端。

Apache Kafka

Azure 事件中心具有内置的 Kafka 终结点，该终结点支持 Kafka 生产者和使用者。 使用 Kafka 生成的应用程序可以使用 Kafka 协议（1.0 或更高版本）通过事件中心发送和接收事件，无需任何代码更改。

Azure SDK 抽象了基础通信协议，并提供了一种使用 C#、Java、Python、JavaScript 等语言通过事件中心发送和接收事件的简化方法。

需要在防火墙上打开哪些端口？

可以将以下协议与 Azure 事件中心配合使用，以便发送和接收事件：

• 高级消息队列协议 1.0 (AMQP)
• 具有传输层安全性的超文本传输协议 1.1 (HTTPS)
• Apache Kafka

请查看下表，了解需要打开哪些出站端口，以便使用这些协议与 Azure 事件中心通信。

在通过端口 5671 使用 AMQP 时，还需要使用 HTTPS 端口进行出站通信，因为客户端 SDK 执行的一些管理操作和从 Microsoft Entra ID（使用时）获取令牌的操作是通过 HTTPS 运行的。

正式的 Azure SDK 通常使用 AMQP 协议通过事件中心发送和接收事件。 与 HTTP API 一样，AMQP-over-WebSockets 协议选项通过端口 TCP 443 运行，但在功能上与普通 AMQP 相同。 由于额外的握手往返，此选项的初始连接延迟较高，并且作为共享 HTTPS 端口的折衷方案，此选项的开销略高。 如果选择此模式，TCP 端口 443 足以进行通信。 以下选项允许选择普通 AMQP 或 AMQP WebSockets 模式：

需要允许哪些 IP 地址？

使用 Azure 时，有时必须在公司防火墙或代理中允许特定的 IP 地址范围或 URL 才能访问正在使用或尝试使用的所有 Azure 服务。 确认在事件中心使用的 IP 地址上是否允许该流量。 有关 Azure 事件中心使用的 IP 地址：请参阅 Azure IP 范围和服务标记 - 公有云。

另外，请验证你的命名空间的 IP 地址是否被允许使用。 若要查找允许你的连接的正确 IP 地址，请执行以下步骤：

1. 从命令提示符处运行以下命令：

   nslookup <YourNamespaceName>.servicebus.chinacloudapi.cn
   

2. 记下 Non-authoritative answer 中返回的 IP 地址。

如果对命名空间使用区域冗余，则需执行一些额外的步骤：

1. 首先，在命名空间中运行 nslookup。

   nslookup <yournamespace>.servicebus.chinacloudapi.cn
   

2. 记下“非权威回答”部分中的名称，该名称采用下述格式之一：

   <name>-s1.chinacloudapp.cn
   <name>-s2.chinacloudapp.cn
   <name>-s3.chinacloudapp.cn
   

3. 为每个实例运行 nslookup，使用后缀 s1、s2 和 s3，以获取在三个可用区中运行的所有三个实例的 IP 地址。

   注意事项

   nslookup 命令返回的 IP 地址不是静态 IP 地址。 但是，在删除基础部署或将其移至其他群集之前，该地址保持不变。

哪些客户端 IP 正在向/从我的命名空间发送/接收事件？

首先，在命名空间上启用 IP 筛选。

然后，按照启用诊断日志中的说明，为事件中心虚拟网络连接事件启用诊断日志。 你会看到连接遭到拒绝的 IP 地址。

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

事件中心提供可由基于 Apache Kafka 的现有应用程序使用的 Kafka 终结点。 只需完成一项配置更改，即可获得 PaaS Kafka 体验。 它提供了一个对于自己运行 Kafka 集群的替代方案。 事件中心支持 Apache Kafka 1.0 和更高版本的客户端，并且适用于现有的 Kafka 应用程序、工具和框架。 有关详细信息，请参阅适用于 Kafka 的事件中心存储库。

若要连接到事件中心，需要更新 Kafka 客户端配置。 为此，可以创建事件中心命名空间并获取连接字符串。 更改 bootstrap.servers，以将事件中心 FQDN 和端口指向 9093。 更新 sasl.jaas.config，将 Kafka 客户端定向到您的事件中心终结点（您已获取的连接字符串），并按照下例正确地进行身份验证：

bootstrap.servers={YOUR.EVENTHUBS.FQDN}:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

例如：

bootstrap.servers=dummynamespace.servicebus.chinacloudapi.cn:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://dummynamespace.servicebus.chinacloudapi.cn/;SharedAccessKeyName=DummyAccessKeyName;SharedAccessKey=XXXXXXXXXXXXXXXXXXXXX";

事件中心允许的最大消息大小为 1 MB。

事件中心内的吞吐量定义通过事件中心传入和传出的数据量，以 MB 或者 1-KB 事件的数目（以千计）为单位。 此吞吐量以吞吐量单位 (TU) 来计量。 在开始使用事件中心服务之前，需购买 TUs。 可以通过使用 Azure 门户或事件中心资源管理器模板显式选择事件中心的吞吐单元 (TU)。

是的，吞吐量单位 (TU) 适用于事件中心命名空间中的所有事件中心。 这意味着，TU 是在命名空间级别购买的，并在该命名空间下的事件中心之间共享。 每个 TU 为命名空间赋予以下功能：

• 入口事件（发送到事件中心的事件）最多为每秒 1 MB，但每秒不得超过 1000 个入口事件、管理操作或控制 API 调用。
• 出口事件（从事件中心消耗的事件）最高为每秒 2 MB，但不超过 4096 个出口事件。
• 事件存储空间最多为 84 GB（对于默认 1 小时保持期而言已足够）。

吞吐量单位 (TU) 按小时计费。 计费基于在指定小时内选择的最大单位数量。

可以从最低一个吞吐量单位 (TU) 开始，并启用自动扩充。 借助自动扩充功能，可以在流量/有效负载增大时增加 TU。 还可以针对 TU 数量设置上限。

借助自动扩充功能，可以纵向扩展吞吐量单位 (TU)。 这意味着您可以先购买较低的 TU，并随着流量的增加，系统将自动扩展 TU 的数量。 它为您提供了一种经济实惠的选择，并让您完全控制要管理的 TU 数量。 这是一个仅限扩容的功能，您可以通过更新来完全控制 TU 数量的缩减。

你可能想要从较低的吞吐量单位 (TU) 开始，例如 2 TU。 如果预测流量可能会增加到 15 TU，请对命名空间启用自动扩充功能，并将最大限制设置为 15 TU。 现在，随着流量的增长，您可以自动扩展您的TU。

此功能不会产生相关的费用。

目前这不可能，因为旧的事件中心命名空间位于不同的群集中，无法将它们迁移到新的群集中。而在创建新的事件中心命名空间时，这些新群集会自动启用区域冗余。

如果某个命名空间中所有事件中心间的总入口吞吐量或总入口事件率超过了聚合吞吐量单位限额，那么发送方会受到限制，并会收到指明已超出入口配额的错误信息。

如果命名空间内所有事件中心的总出口吞吐量或总事件出口率超过了聚合吞吐量单位限额，接收方会受到限制处理，但不会生成任何限制错误。

入口和出口配额是分开强制实施的，因此，任何发送方都不会使事件耗用速度减慢，并且接收方也无法阻止事件发送到事件中心。

在 Azure 门户中创建基本层或标准层命名空间时，最多可以为命名空间选择 40 个 TU。 超过 40 个 TU 时，事件中心提供基于资源/容量的模型，例如事件中心 Premium 群集。 有关详细信息，请参阅 事件中心高级版 - 概述。

分区是一种支持并行发布和使用的数据组织机制。 虽然它支持并行处理和缩放，但总容量仍受命名空间的缩放分配的限制。 将扩展单元（标准层的吞吐量单元、高级层的处理单元或专用层的容量单元）与分区相平衡，以实现最佳扩展。

从工作负载概况开始：平均有效负载大小、每秒事件数，以及对吞吐量下降或延迟峰值的敏感度。 使用下面的每分区吞吐量作为起点，然后使用负载测试进行验证：

• 标准层：约 1 MB/秒的入口，每个分区的出口量约为 2 MB/秒。
• 高级和专用层：每个分区大约 1-2 MB/每秒的入站带宽和大约 2-5 MB/每秒的出站带宽。

通过将预期的入口和出口除以适用的每分区的速率，然后取其中较大值来估算分区。 如果观察到的吞吐量或延迟不符合预期，请增加分区（仅限高级层和专用层）并重新测试。

分区还设置使用者并行度上限。 上限的工作原理取决于使用者类型：

• 由 （.NET， Java） 和 （Python， JavaScript） 使用的 EventProcessorClientEventHubConsumerClient，这是生产 AMQP 工作负荷的建议模式。 在一个使用者组中，同一时刻仅有一个 Epoch 使用者可以拥有某个特定分区。 如果部署的处理器实例数多于分区，则在现有所有者释放一个分区之前，不会分配额外的实例并处于空闲状态。 如果新的 epoch 使用者使用更高的所有者级别进行连接，则服务会断开当前所有者的连接并显示 ConsumerDisconnected 错误，并且新使用者接管。
• 非纪元使用者 最多 5 个非纪元接收器可以在使用者组中并发读取同一分区。 每个接收方都会看到相同的事件（扇出），因此此模式不会增加每个分区的处理吞吐量。 将纪元使用者连接到分区会断开该分区上所有非纪元使用者的连接。
• Kafka 使用者 Kafka 使用者使用组协调协议（group.id）而不是 AMQP 纪元，但分区所有权模型是等效的：每个分区一次分配给使用者组中的一个使用者成员。 当新成员加入或现有成员离开时，组会重新平衡并重新分配分区分配。 如果使用者成员数多于分区，则多余的成员不会收到任何分配，并且会保持空闲状态，直到将来重新平衡释放分区。 若要减少由于暂时性断开连接而导致的不必要的重新平衡，请为每个使用者实例设置唯一的group.instance.id（静态成员身份）。

实际上，分区数等于每个消费者组的最大并行消费者数，无论使用的是 AMQP 纪元消费者还是 Kafka 消费者。 在规划横向扩展时，应将这个因素考虑到分区计数中。

如果应用程序具有与特定分区的相关性，则增加分区数并不有益。 有关详细信息，请参阅可用性和一致性。

不可以，因为分区在标准层中是不可变的。 只能在事件中心的高级层和专用层中动态增加分区。

有关事件中心定价的完整信息，请参阅事件中心定价详细信息。

事件中心标准层允许消息保留期长于 24 小时，最长以 7 天为限。 如果所存储事件总量的大小超过所选吞吐量单位数量的存储限制（每个吞吐量单位 84 GB），超出限制的部分会按公布的 Azure Blob 存储区费率收费。 每个吞吐量单元的存储容量涵盖 24 小时保留期的所有存储成本，即使吞吐量单元已经达到最大入口容量限制。

所有存储的事件的总大小（包括所有事件中心内事件标头或磁盘存储器结构上的所有内部开销）按整天计量。 在一天结束时，计算存储区大小峰值。 每天的存储限制根据在当天所选择的吞吐量单元的最小数量（每个吞吐量单元提供 84 GB 的限制）来计算。 如果总大小超过计算出的每日存储限额，超出的存储量会采用 Azure Blob 存储费率（按本地冗余存储费率）来计费。

发送到事件中心的每个事件均计为一条可计费消息。 入口事件定义为小于或等于 64 KB 的数据单元。 任何大小小于或等于 64 KB 的事件都被视为一个计费事件。 如果该事件大于 64 KB，则根据事件大小按 64 KB 的倍数来计算计费事件的数量。 例如，发送到事件中心的 8-KB 事件按一个事件计费，而发送到事件中心的 96-KB 的消息则按两个事件计费。

从事件中心耗用的事件以及管理操作和控制调用（例如检查点）不计为计费入口事件，但会累计，其上限为吞吐量单位限额。

连接费用只在使用 AMQP 协议时适用。 使用 HTTP 发送事件没有连接费用，无论发送系统或设备的数量是多少。 如果计划使用 AMQP（例如，为了实现更高效的事件流式传输，或者为了对 IoT 命令和控制方案启用双向通信），请参阅事件中心定价信息页，了解有关每个服务层级中包括多少连接的详细信息。

命名空间中的任何事件中心启用了捕获选项时，即可启用捕获功能。 事件中心捕获按所购买的吞吐量单位按月计费。 当吞吐量单位计数增加或减少时，“事件中心捕获”计费将以整小时为增量反映这些变化。 有关事件中心捕获计费的详细信息，请参阅事件中心定价信息。

在事件中心启用捕获时，捕获使用您提供的存储帐户。 因为这是你的存储帐户，任何针对此配置的费用更改都将计入你的 Azure 订阅。

如需所有 Event Hubs 配额的列表，请参阅 配额。

从订阅中删除命名空间时，请等待 4 个小时，然后才能在另一个订阅中使用相同的名称重新创建它。 否则，可能会收到以下错误消息：Namespace already exists。

有关可能的事件中心异常的列表，请参阅异常概述。

事件中心支持两种类型的诊断日志 - 捕获错误日志和操作日志 - 这两种日志都用 json 表示并可以通过 Azure 门户启用。

事件中心的技术支持可通过 Azure 服务总线的 Microsoft 问答页面获取。 计费和订阅管理支持免费提供。

若要详细了解我们的 SLA，请参阅服务级别协议页面。

如果在 Azure Stack Hub 上运行此代码，除非将特定的存储 API 版本作为目标，否则会遇到运行时错误。 这是因为事件中心 SDK 使用 Azure 中提供的最新可用 Azure 存储 API，而此 API 可能在 Azure Stack Hub 平台上不可用。 Azure Stack Hub 支持的存储 Blob SDK 版本可能与 Azure 上通常提供的版本不同。 如果你是将 Azure Blob 存储用作检查点存储，请检查支持用于 Azure Stack Hub 内部版本的 Azure 存储 API 版本，并在代码中将该版本作为目标。

例如，如果在 Azure Stack Hub 版本 2005 上运行，则存储服务的最高可用版本为版本 2019-02-02。 默认情况下，事件中心 SDK 客户端库使用 Azure 上的最高可用版本（在 SDK 发布时为 2019-07-07）。 在这种情况下，除了执行本部分中的步骤以外，还需要添加相关代码，将存储服务 API 版本 2019-02-02 作为目标。 如需通过示例来了解如何以特定的存储 API 版本为目标，请参阅以下 C#、Java、Python 和 JavaScript/TypeScript 示例。

如需通过示例来了解如何从代码中以特定存储 API 版本为目标，请参阅 GitHub 上的以下示例：

• .NET
• Java
• Python - 同步、异步
• JavaScript 和 TypeScript

后续步骤

访问以下链接可以了解有关事件中心的详细信息：

• 事件中心概述
• 创建事件中心
• 事件中心自动膨胀