你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 事件中心的功能和术语
Azure 事件中心是可缩放的事件处理服务，它引入并处理大量事件和数据，具有低延迟和高可靠性。 有关服务的高级概述，请参阅什么是事件中心？。
本文基于概述文章中的信息编写，并提供有关事件中心组件和功能的技术和实现详细信息。
命名空间
事件中心命名空间是事件中心（在 Kafka 术语中称为“主题”）的管理容器。 事件中心命名空间提供 DNS 集成网络终结点与一系列的访问控制和网络集成管理功能（例如 IP 筛选、虚拟网络服务终结点和专用链接）。
分区
事件中心将发送到事件中心的事件序列组织到一个或多个分区中。 当较新的事件到达时，它们将添加到此序列的末尾。
可以将分区视为提交日志。 分区可保存包含以下信息的事件数据：
- 事件的正文
- 描述事件的用户定义的属性包
- 元数据（如分区中的偏移量、流序列中的编号）
- 接受它的服务端时间戳
使用分区的优势
事件中心旨在帮助处理量较大的事件，分区通过两种方式对此提供帮助：
- 即使事件中心是 PaaS 服务，但其下面也存在物理现实。 维护保留事件顺序的日志要求将这些事件保存在基础存储及其副本中，这会导致此类日志存在吞吐量上限。 通过使用分区，可以将多个并行日志用于同一个事件中心，从而使可用的原始输入输出 (IO) 吞吐容量倍增。
- 你自己的应用程序必须能够及时处理要发送到事件中心的事件量。 它可能很复杂，并且需要大量的横向扩展并行处理容量。 用于处理事件的单个进程的容量有限，因此需要多个进程。 分区是解决方案为这些进程供给容量的一种方式，它们还能确保每个事件都有一个明确的处理所有者。
分区数
分区数在创建事件中心时指定。 该数值必须介于 1 和每个定价层允许的最大分区数之间。 有关每个层的分区计数限制，请参阅此文。
建议在特定事件中心的应用程序峰值负载期间，至少选择你预期需要的分区数。 对于高级层和专用层以外的层，创建事件中心后无法更改其分区计数。 对于高级或专用层中的事件中心，可以在创建后增加分区计数，但不能减少分区计数。 当分区键到分区的映射发生更改时，流在分区之间的分布也会发生更改，因此如果应用程序中事件的相对顺序很重要，你应该尽力避免此类更改。
将分区数设置为允许的最大值很有吸引力，但请始终记住，事件流需要进行结构化，这样你才能真正利用多个分区。 如果需要跨所有事件或仅少数几个子流保持绝对顺序，则你可能无法利用多个分区。 而且，多个分区会使处理端更加复杂。
在定价方面，事件中心中具有多少个分区并不重要。 这取决于命名空间或专用群集的定价单位数量（标准层为吞吐量单位 (TU)、高级层为处理单位 (PU)、专用层为容量单位 (CU)）。 例如，当命名空间设置为 1 TU 容量时，具有 32 个分区或 1 个分区的标准层的事件中心会产生完全相同的费用。 此外，你可以缩放命名空间的 TU 或 PU 或者专用群集的 CU，而不管分区计数如何。
由于分区是一种数据组织机制，支持以并行方式发布和使用数据。 我们建议均衡缩放单位（标准层的吞吐量单位、高级层的处理单位或专用层的容量单位）和分区，以实现最佳缩放。 通常情况下，建议将每个分区的最大吞吐量设置为 1 MB/秒。 因此，计算分区数的一项经验规则是将最大预期吞吐量除以 1 MB/秒。 例如，如果用例需要 20 MB/秒，则建议至少选择 20 个分区来实现最佳吞吐量。
但如果已有一个模型，其中的应用程序与特定分区存在相关性，则增加分区数量可能无用。 有关详细信息，请参阅可用性和一致性。
事件到分区的映射
可以使用分区键将传入事件数据映射到特定分区，以便进行数据组织。 分区键是发送者提供的、要传递给事件中心的值。 该键通过静态哈希函数进行处理，以便分配分区。 如果在发布事件时未指定分区键，则会使用循环分配。
事件发布者只知道其分区密钥，而不知道事件要发布到的分区。 键与分区的这种分离使发送者无需了解有关下游处理的过多信息。 每个设备或用户的唯一标识就可以充当一个适当的分区键，但是，也可以使用其他属性（例如地理位置），以便将相关的事件分组到单个分区中。
通过指定分区键，可使相关事件保持在同一分区中，并按其到达的确切顺序排列。 分区键是派生自应用程序上下文并标识事件之间的相互关系的字符串。 分区键标识的事件序列是一个流。 分区是针对许多此类流的多路复用日志存储。
注意
尽管你可以直接向分区发送事件，但我们不建议这样做，尤其是保持高可用性至关重要时。 这种做法会将事件中心的可用性降级到分区级别。 有关详细信息，请参阅可用性和一致性。
事件发布者
任何向事件中心发送数据的实体都是事件发布者（与“事件生成者”同义） 。 事件发布者可以使用 HTTPS、AMQP 1.0 或 Kafka 协议发布事件。 事件发布者会将基于 Microsoft Entra ID 的授权与 OAuth2 颁发的 JWT 令牌或特定于事件中心的共享访问签名 (SAS) 令牌配合使用，从而获取发布访问权限。
可以通过 AMQP 1.0、Kafka 协议或 HTTPS 发布事件。 事件中心服务提供 REST API、.NET、Java、Python、JavaScript 和 Go 客户端库，用于将事件发布到事件中心。 对于其他运行时和平台，可以使用任何 AMQP 1.0 客户端，例如 Apache Qpid。
是要使用 AMQP 还 HTTPS 根据具体的使用方案而定。 AMQP 除了需要使用传输级别安全 (TLS) 或 SSL/TLS 以外，还需要建立持久的双向套接字。 初始化会话时，AMQP 具有较高的网络成本，但是 HTTPS 需要为每个请求使用额外的 TLS 开销。 对于频繁进行发布的发布者，AMQP 的性能更高，并且，在将 AMQP 与异步发布代码配合使用时，延迟可能会大大降低。
可以逐个或者成批发送事件。 单个发布的限制为 1 MB，不管它是单个事件还是一批事件。 发布大于此阈值的事件将被拒绝。
事件中心吞吐量是通过使用分区和吞吐量单位分配进行缩放的。 发布者最好不要知道为事件中心选择的特定分区模型，而只是指定用于一致地将相关事件分配给同一分区的分区键。
事件中心确保共享分区键值的所有事件存储在一起，并按到达顺序进行传递。 如果将分区键与发布者策略结合使用，则发布者的标识与分区键的值必须匹配。 否则会出错。
事件保留
根据可配置的基于时间的保留策略从事件中心删除已发布的事件。 下面是一些要点：
- 默认值和最短可能的保持期为 1 小时。
- 对于事件中心“标准”层，最长保留期为“7 天” 。
- 对于“高级”和“专用”事件中心，最长保留期为 90 天。
- 如果你更改保持期，更改后的设置将应用于所有事件，包括事件中心内已有的事件。
事件中心在配置的保留时间内保留事件，该时间适用于所有分区。 达到保持期后，事件自动被删除。 如果指定的保持期为一天（24 小时），则该事件将在被接受后的 24 小时后变为不可用。 无法显式地删除事件。
如果需要将事件存档到超过允许的保留期，可以通过打开“事件中心捕获”功能将事件自动存储在 Azure 存储或 Azure Data Lake 中。 如果需要搜索或分析此类深层存档，可以轻松地将其导入 Azure Synapse 或其他类似的存储和分析平台。
事件中心的数据保留限制以时间为基础，其原因是为了防止大量的历史客户数据被捕获到仅由时间戳索引且仅允许顺序访问的深层存储中。 此处的体系结构理念是，历史数据需要比事件中心或 Kafka 提供的实时事件接口更丰富的索引和更直接的访问。 事件流式处理引擎不太适合充当用于事件溯源的数据湖或长期存档。
注意
事件中心是一个实时事件流引擎，其设计意图并不是用于代替数据库以及/或者用作无限期保存的事件流的永久存储。
事件流的历史记录越久远，查找给定流的特定历史切片所需的辅助索引就越多。 检查事件负载和索引不在事件中心（或 Apache Kafka）的功能范围内。 因此，数据库以及专用分析存储和引擎（如 Azure Data Lake Store、Azure Data Lake Analytics 和 Azure Synapse）明显更适合用于存储历史事件。
事件中心捕获直接与 Azure Blob 存储和 Azure Data Lake Storage 集成，通过这种集成，还可以实现直接将事件传入 Azure Synapse。
发布者策略
使用事件中心可以通过发布者策略对事件发布者进行精细控制。 发布者策略是运行时功能，旨在为大量的独立事件发布者提供方便。 借助发布者策略，每个发布者在使用以下机制将事件发布到事件中心时可以使用自身的唯一标识符：
//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>
不需要提前创建发布者名称，但它们必须与发布事件时使用的 SAS 令牌匹配，以确保发布者标识保持独立。 使用发布者策略时，需要将 PartitionKey 值设置为发布者名称。 若要正常工作，这些值必须匹配。
捕获
使用事件中心捕获，可以自动捕获事件中心的流式处理数据，并将其保存到所选 Blob 存储帐户或 Azure Data Lake 存储帐户。 可以从 Azure 门户启用捕获，并指定大小上限和时间范围以执行捕获。 使用事件中心捕获，用户可以指定自己的 Azure Blob 存储帐户和容器或 Azure Data Lake 存储帐户（其中之一用于存储捕获的数据）。 捕获的数据以 Apache Avro 格式编写。
事件中心捕获生成的文件具有以下 Avro 架构：
注意
在 Azure 门户中不使用代码编辑器时，可以使用 Parquet 格式的 Azure Data Lake Storage Gen2 帐户在事件中心捕获流式处理数据。 有关详细信息，请参阅如何：以 Parquet 格式捕获事件中心数据和教程：使用 Azure Synapse Analytics 捕获 parquet 格式的事件中心数据并进行分析。
SAS 令牌
事件中心使用在命名空间和事件中心级别提供的共享访问签名。 SAS 令牌是从 SAS 密钥生成的，它是以特定格式编码的 URL 的 SHA 哈希。 事件中心可以使用密钥（策略）的名称和令牌重新生成哈希，从而对发送者进行身份验证。 通常，为事件发布者创建的 SAS 令牌只对特定的事件中心具有“发送”权限。 此 SAS 令牌 URL 机制是“发布者策略”中介绍的发布者标识的基础。 有关使用 SAS 的详细信息，请参阅使用服务总线进行共享访问签名身份验证。
事件使用者
从事件中心读取事件数据的任何实体称为“事件使用者”。 使用者或接收者使用 AMQP 或 Apache Kafka 从事件中心接收事件。 事件中心仅支持使用者通过拉取模型从中接收事件。 即使你使用事件处理程序来处理来自事件中心的事件，事件处理器内部也会使用拉取模型来接收来自事件中心的事件。
使用者组
事件中心的发布/订阅机制通过“使用者组”启用。 使用者组是从事件中心或 Kafka 主题读取数据的使用者的逻辑分组。 它使多个使用应用程序能够按照自己的节奏及其偏移量独立读取事件中心中的相同流数据。 它允许并行使用消息，并在多个使用者之间分配工作负载，同时保持每个分区中消息的顺序。
我们建议在使用者组中一个分区上只有一个活动接收器。 但在某些情况下，每个分区最多可以使用 5 个使用者或接收器，其中所有接收器会获取分区的所有事件。 如果在同一分区上有多个读取者，则处理重复事件。 你需要在代码中处理它，这并不简单。 但是，在某些情况下，这是一种有效的方法。
在流处理体系结构中，每个下游应用程序相当于一个使用者组。 如果要将事件数据写入长期存储，则该存储写入器应用程序就是一个使用者组。 然后，复杂的事件处理可由另一个独立的使用者组执行。 只能通过使用者组访问分区。 事件中心内始终有一个默认使用者组，你最多可以为相应的定价层创建最大数量的使用者组。
Azure SDK 提供的某些客户端是智能使用者代理，可以自动管理详细信息，以确保每个分区都有一个读取者，并确保正在读取事件中心的所有分区。 这样，你的代码的处理范围便可集中于从事件中心读取的事件，从而可以忽略分区的许多细节。 有关详细信息，请参阅连接到分区。
以下示例显示了使用者组 URI 约定：
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>
下图显示了事件中心流处理体系结构：
流偏移量
偏移量 是事件在分区中的位置。 可以将偏移量视为客户端游标。 偏移量是事件的字节编号。 有了该偏移量，事件使用者（读取者）便可以在事件流中指定要从其开始读取事件的点。 可以时间戳或者偏移量值的形式指定偏移量。 使用者负责在事件中心服务的外部存储其自身的偏移量值。 在分区中，每个事件都包含一个偏移量。
检查点
检查点 是读取者在分区事件序列中标记或提交其位置时执行的过程。 检查点操作由使用者负责，并在使用者组中的每个分区上进行。 这种责任意味着，对于每个使用者组而言，每个分区读取者必须跟踪它在事件流中的当前位置，当它认为数据流已完成时，可以通知服务。
如果读取者与分区断开连接，当它重新连接时，将开始读取前面由该使用者组中该分区的最后一个读取者提交的检查点。 当读取者建立连接时，它会将此偏移量传递给事件中心，以指定要从其开始读取数据的位置。 这样，用户便可以使用检查点将事件标记为已由下游应用程序“完成”，并且在不同计算机上运行的读取者之间发生故障转移时，还可以提供弹性。 可通过在此检查点过程中指定较低偏移量，返回到较旧的数据。 借助此机制，检查点可以实现故障转移复原和事件流重放。
重要
偏移量由事件中心服务提供。 处理事件时，由使用者负责提供检查点。
使用 Azure Blob 存储作为检查点存储时，请遵循以下建议：
- 对每个使用者组使用单独的容器。 可以使用同一存储帐户，但每个组使用一个容器。
- 请勿将容器用于任何其他用途，也不要将存储帐户用于任何其他用途。
- 存储帐户应位于部署的应用程序所在的同一区域中。 如果应用程序位于本地，请尝试选择最近的区域。
在 Azure 门户的“存储帐户”页上的“Blob 服务”部分，确保禁用以下设置。
- 分层命名空间
- Blob 软删除
- 版本控制
日志压缩
Azure 事件中心支持压缩事件日志，以保留给定事件键的最新事件。 使用压缩事件中心/Kafka 主题时，可以使用基于键的保留，而不使用更粗粒度的基于时间的保留。
有关日志压缩的详细信息，请参阅日志压缩。
常见的使用者任务
所有事件中心使用者都通过 AMQP 1.0 会话，一种状态感知型双向信道进行连接。 每个分区都提供一个 AMQP 1.0 会话，方便传输按分区隔离的事件。
连接到分区
在连接到分区时，常见的做法是使用租用机制来协调读取者与特定分区的连接。 这样，便可以做到一个使用者组中每分区只有一个活动的读取者。 使用事件中心 SDK 中的客户端（充当智能使用者代理）可以简化检查点、租用和管理读取者的操作。 它们是：
- 适用于 .NET 的 EventProcessorClient
- 适用于 Java 的 EventProcessorClient
- 适用于 Python 的 EventHubConsumerClient
- 适用于 JavaScript/TypeScript 的 EventHubConsumerClient
读取事件
为特定分区建立 AMQP 1.0 会话和链接后，事件中心服务会将事件传送到 AMQP 1.0 客户端。 与 HTTP GET 等基于提取的机制相比，此传送机制可以实现更高的吞吐量和更低的延迟。 将事件发送到客户端时，每个事件数据实例包含重要的元数据，例如，用于简化对事件序列执行的检查点操作的偏移量和序列号。
事件数据：
- Offset
- 序列号
- 正文
- 用户属性
- 系统属性
管理偏移量由用户负责。
应用程序组
应用程序组是一个客户端应用程序集合，这些应用程序连接到一个共享唯一标识条件的事件中心命名空间，例如安全性上下文 - 共享访问策略或 Microsoft Entra 应用程序 ID。
Azure 事件中心使你能够为给定应用程序组定义资源访问策略（例如限制策略），并在客户端应用程序与事件中心之间控制事件流式处理（发布或使用）。
有关详细信息，请参阅使用应用程序组治理客户端应用程序资源。
Apache Kafka 支持
Apache Kafka 客户端（版本> =1.0）的协议支持提供了支持现有 Kafka 应用程序使用事件中心的终结点。 可以将大多数现有 Kafka 应用程序重新配置为指向 s 命名空间而不是 Kafka 群集启动服务器。
从成本、运营工作量和可靠性的角度看，Azure 事件中心不仅能够很好地替代部署和操作你自己的 Kafka 和 Zookeeper 群集的做法，而且还能完美替代非 Azure 原生的“Kafka 即服务”产品。
除了获取 Apache Kafka 中转站的核心功能以外，你还可以访问 Azure 事件中心的各项功能，例如，通过事件中心捕获进行自动批处理和存档、自动缩放和均衡、灾难恢复、成本中性可用性区域支持、灵活且安全的网络集成，以及多协议支持（包括防火墙友好的基于 WebSocket 的 AMQP 协议）。
协议
生产者或发送者可以使用高级消息队列协议 (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 等语言通过事件中心发送和接收事件的简化方法。
后续步骤
有关事件中心的详细信息，请访问以下链接：
- 事件中心入门