事件中心功能和术语

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

概念一目了然

Architecture

命名空间

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

分区

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

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

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

使用分区的优势

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

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

分区数

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

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

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

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

分区是一种支持并行发布和消耗的数据组织机制。 虽然它支持并行处理和缩放，但总容量仍受命名空间的缩放分配的限制。 建议平衡缩放单位（标准层的吞吐量单位、高级层的处理单位）和分区，以实现最佳缩放。 通常情况下，建议将每个分区的最大吞吐量设置为 1 MB/秒。 因此，计算分区数的一项经验规则是将最大预期吞吐量除以 1 MB/秒。 例如，如果用例需要 20 MB/秒，则建议至少选择 20 个分区来实现最佳吞吐量。

但如果已有一个模型，其中的应用程序与特定分区存在相关性，则增加分区数量可能无用。 有关详细信息，请参阅可用性和一致性。

事件到分区的映射

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

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

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

事件生成者

生成者（或发布者）是将事件发送到事件中心的任何应用程序。

发布选项

关键行为

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

发布者策略

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

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

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

事件使用者

使用者是从事件中心读取事件的任何应用程序。 事件中心使用 拉取模型使用者请求事件，而不是向其推送事件。

使用者组

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

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

偏移量

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

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

检查点

检查点 是指消费者保存其当前偏移量的时刻。 这使得：

• 恢复：如果使用者断开连接，它将从最后一个检查点恢复
• 故障转移：新的消费者实例可以从上一个实例停止的位置继续接管
• 重播：通过指定以前的偏移量来处理历史事件

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

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

在 Azure 门户的“存储帐户”页上的“Blob 服务”部分，确保禁用以下设置。

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

事件处理程序客户端

Azure SDK 提供智能使用者客户端，用于自动处理分区管理、负载均衡和检查点：

事件数据结构

每个事件都包含：

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

数据管理

事件保留

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

要点：

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

事件中心捕获

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

日志压缩

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

协议

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

协议比较

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

有关 Kafka 集成详细信息，请参阅 Apache Kafka 的事件中心。

存取控制

Microsoft Entra ID

Microsoft Entra ID 通过基于角色的访问控制（RBAC）提供 OAuth 2.0 身份验证。 分配内置角色来控制访问：

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

共享访问签名 （SAS）

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

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

应用程序组

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

相关内容

开始

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

了解详细信息

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

Reference

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