事件中心功能和术语

本文介绍Azure Event Hubs的核心概念和术语。 有关概要概述，请参阅 什么是事件中心？

概念一目了然

Architecture

命名空间

事件中心 命名空间 是事件中心（或 Kafka 术语中的主题）的管理容器。 它通过IP 筛选、虚拟网络服务终结点和Private Link等功能提供网络终结点和控制访问。

分区

事件中心将发送到事件中心的事件序列组织到一个或多个分区中。 当较新的事件到达时，它们将添加到此序列的末尾。

可以将分区视为提交日志。 分区可保存包含以下信息的事件数据：

• 事件的正文
• 描述事件的用户定义的属性包
• 元数据（如分区中的偏移量、流序列中的编号）
• 服务端接受时的时间戳

使用分区的优势

事件中心旨在帮助处理量较大的事件，分区通过两种方式对此提供帮助：

• 即使事件中心是 PaaS 服务，但其下面也存在物理现实。 维护一个保持事件顺序的日志要求这些事件在基础存储及其副本中一起保存，这会导致该日志的吞吐量达到上限。 通过使用分区，可以将多个并行日志用于同一个事件中心，从而使可用的原始输入输出 (IO) 吞吐容量倍增。
• 你自己的应用程序必须能够及时处理要发送到事件中心的事件量。 它可能很复杂，并且需要大量的横向扩展并行处理容量。 用于处理事件的单个进程的容量有限，因此需要多个进程。 分区是您的解决方案向这些进程提供数据的方式，并确保每个事件都有明确的处理负责主体。

分区数

分区数在创建事件中心时指定。 该数值必须介于 1 和每个定价层允许的最大分区数之间。 有关每个层的分区计数限制，请参阅此文。

建议在特定事件中心的应用程序峰值负载期间，至少选择你预期需要的分区数。 对于高级层以外的层，创建事件中心后无法更改其分区计数。 对于在高级层的事件中心，可以在创建后增加分区数量，但不能减少分区数量。 分区键到分区的映射一旦发生更改，流在各分区之间的分布也会随之改变。因此，如果应用程序中的事件顺序很重要，你应该尽量避免此类更改。

将分区数设置为允许的最大值很有吸引力，但请始终记住，事件流需要进行结构化，这样你才能真正利用多个分区。 如果需要在所有事件或少数几个子流中保持绝对顺序，那么你可能无法利用多个分区。 而且，多个分区会使处理端更加复杂。

在定价方面，事件中心中具有多少个分区并不重要。 这取决于定价单位的数量（标准层的吞吐量单位（TU），高级层群集的处理单位（PU））。 例如，当命名空间设置为 1 TU 容量时，具有 32 个分区或 1 个分区的标准层的事件中心会产生完全相同的费用。

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

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

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

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

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

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

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

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

事件到分区的映射

可以使用分区键将传入事件数据映射到特定分区，以便进行数据组织。 分区键是发送者提供的、要传递给事件中心的值。 该键通过静态哈希函数进行处理，创建分区分配。 如果在发布事件时未指定分区键，则会使用循环分配。

事件发布者仅知道其分区键，而不是发布事件的分区。 键与分区的这种分离使发送者无需了解有关下游处理的过多信息。 每个设备或用户的唯一标识就可以充当一个适当的分区键，但是，也可以使用其他属性（例如地理位置），以便将相关的事件分组到单个分区中。

通过指定分区键，可使相关事件保持在同一分区中，并按其到达的确切顺序排列。 分区键是派生自应用程序上下文并标识事件之间的相互关系的字符串。 分区键标识的事件序列是一个流。 分区是针对许多此类流的多路复用日志存储。

事件生成者

producer（或publisher）是将事件发送到事件中心的任何应用程序。

发布选项

关键行为

• 批处理或单独：一次发布事件或分批发布事件。 每次发布操作最多 1 MB。
• 分区键：指定分区键以将同一分区中的相关事件分组，确保有序传递。
• Authorization：将Microsoft Entra ID（OAuth2）或共享访问签名（SAS）用于访问控制。

发布者的策略

Publisher策略可在拥有许多独立发布者时实现精细控制。 每个publisher都使用唯一标识符：

//<my namespace>.servicebus.chinacloudapi.cn/<event hub name>/publishers/<my publisher name>

发布者名称必须与用于身份验证的 SAS 令牌匹配。 使用publisher策略时，PartitionKey必须与publisher名称匹配。

事件使用者

consumer是从事件中心读取事件的任何应用程序。 事件中心使用 拉取模型——消费者请求事件，而不是将事件推送给他们。

消费者组

消费者组是事件流的独立视图。 多个消费者组可以同时读取相同的事件中心，每个组都追踪自己的位置。

//<my namespace>.servicebus.chinacloudapi.cn/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.chinacloudapi.cn/<event hub name>/<Consumer Group #2>

偏移量

偏移量是事件在分区中的位置， 将其视为游标。 使用者使用偏移量来指定开始读取的位置。 可以从以下开始：

• 特定偏移值
• 时间戳
• 流的开头或结尾

检查点

Checkpointing是指消费者保存其当前偏移量的操作。 这使得：

• Resumption，如果消费者断开连接，它将从最后一个检查点恢复
• Failover：新的consumer实例可以从另一个离开位置接管
• 重播：通过指定以前的偏移量来处理历史事件

使用Azure Blob Storage作为检查点存储时，请遵循以下建议：

• 为每个消费者组使用单独的容器。 可以使用同一个存储帐户，但每个组使用一个容器。
• 不要将存储帐户用于其他任何内容。
• 不要将容器用于任何其他用途。
• 在部署的应用程序所在的同一区域中创建storage帐户。 如果应用程序位于本地，请尝试选择最近的区域。

在 Azure portal 的 Storage 帐户页面的 Blob 服务部分，确保禁用以下设置。

• 分层命名空间
• Blob 软删除
• 版本控制

事件处理程序客户端

Azure SDK 提供智能的消费者客户端，可以自动处理分区管理、负载均衡和检查点管理。

事件数据结构

每个事件都包含：

• 正文：事件有效负载
• 偏移量：分区中的位置
• 序列号：分区内的顺序
• 用户属性：自定义元数据
• 系统属性：服务分配的元数据（排队时间等）

数据管理

事件保留

根据基于时间的保留策略自动删除事件。

要点：

• 无法显式删除事件
• 保留政策的更改适用于现有事件
• 当保留期到期时，事件就变得不可用

事件中心捕获

Capture会自动将流数据保存到Azure Blob Storage或Azure Data Lake Storage。 配置最小大小和时间范围以控制捕获频率。

日志压缩

日志压缩 仅保留每个唯一密钥的最新事件，而不是使用基于时间的保留。 用于维护当前状态而不存储完整历史记录。

协议

事件中心支持多个协议，以便跨不同的客户端类型灵活。

协议比较

• AMQP：需要持久性双向套接字。 初始成本较高，但频繁操作时性能更好。 由 Azure SDK 使用。
• Kafka：本机支持意味着现有 Kafka 应用程序无需更改代码即可工作。 只需重新配置引导服务器，使其指向你的事件中心命名空间。
• HTTPS：用于发送的简单 HTTP POST。 没有收到支持。 适合偶尔低量发布。

有关 Kafka 集成详细信息，请参阅适用于 Apache Kafka 的 Event Hubs。

访问控制

Microsoft Entra ID

Microsoft Entra ID 通过 OAuth 2.0 的身份验证和基于角色的访问控制 (RBAC) 提供服务。 分配内置角色来控制访问。

有关详细信息，请参阅 使用 Microsoft Entra ID 授权访问。

共享访问签名（SAS）

SAS 令牌在命名空间或事件中心级别提供限定的访问权限。 SAS 令牌是从 SAS 密钥生成的，通常仅授予 发送 或 侦听 权限。

有关详细信息，请参阅 共享Access签名身份验证。

应用程序组

为共享安全上下文（SAS 策略或 Microsoft Entra 应用程序 ID）的客户端应用程序集合定义资源访问策略（例如限流）。

相关内容

开始使用

• .NET 快速入门
• Java 快速入门
• Python 快速入门
• JavaScript 快速入门

了解详细信息

• 可伸缩性和吞吐量单位
• 可用性和一致性
• 事件中心数据捕获概述
• 适用于 Apache Kafka 的 Event Hubs

Reference

• 配额和限制
• 事件中心常见问题
• 事件中心示例