使用 Azure 事件中心实现缩放

有两个因素会影响事件中心的缩放。

• 吞吐量单位（标准层）或处理单位（高级层）
• 分区

吞吐量单位

吞吐量单位控制事件中心的吞吐量容量。 吞吐量单位是预先购买的容量单位。 单个吞吐量单元提供以下功能：

• 流入量：最高每秒 1 MB，或每秒 1000 个事件（以先达到的限制为准）。
• 流出量：最高每秒 2 MB，或每秒 4096 个事件。

如果超出了你购买的吞吐量单位的容量，则会限制流入量，事件中心会引发一个 EventHubsException，其原因值为 ServiceBusy。 流出量不会产生限制异常，但仍不能超出所购买的吞吐量单位的容量。 如果收到发布速率异常或预期看到更高的出口流量，请检查为命名空间购买的吞吐量单位数。 可以在 Azure 门户的命名空间的“规模”页面上管理吞吐量单位。 还可以使用 事件中心 API 以编程方式管理吞吐量单位。

可以预购吞吐量单位，并按小时付费。 购买吞吐量单位后，至少需支付一小时的费用。 可以为事件中心命名空间购买最多 40 个吞吐量单位，该命名空间中的所有事件中心共享这些吞吐量单位。 每个事件中心中的所有分区和使用者共享这些吞吐量单位的总入口和出口容量，因此多个使用者从同一分区读取共享可用带宽。

事件中心的 自动扩展 功能通过增加吞吐量单位数来满足使用需求。 增加吞吐单元可预防出现限流情况，在这些情况下：

• 数据入口速率超过设置的吞吐量单位数。
• 数据出口请求速率超过设置的吞吐量单位数。

当负载的增加超过最小阈值时，事件中心服务会增加吞吐量，不会因服务器繁忙错误导致任何请求失败。

有关自动扩展功能的详细信息，请参阅自动扩展吞吐量单位。

处理单位

事件中心高级层在托管的多租户 PaaS 环境中提供了卓越的性能和更好的隔离性。 高级层中的资源在 CPU 和内存级别隔离，因此每个租户工作负荷都独立运行。 此资源容器称为“处理单位”(PU)。 可以为每个事件中心高级层命名空间购买 1、2、4、6、8、10、12 或 16 个处理单位。

使用处理单位可以引入和流式传输的数据量取决于各种因素，例如生成者、使用者、引入和处理速率，等等。

例如，对于 AMQP 和 Kafka 工作负载，具有 1 个 PU 和 1 个事件中心（100 个分区）的事件中心高级版命名空间大约可以提供 ~5-10 MB/秒流入量和 10-20 MB/秒流出量的核心容量。

有关为高级层命名空间配置 PU 的详细信息，请参阅 “配置处理单元”。

分区

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

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

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

使用分区的优势

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

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

分区数

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

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

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

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

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

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

• 标准层：约 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 消费者。 在规划横向扩展时，应将这个因素考虑到分区计数中。

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

事件到分区的映射

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

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

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

相关内容

若要了解有关事件中心的详细信息，请参阅以下文章：

• 自动调整标准层命名空间的吞吐量单位
• 配置高级层命名空间的处理单位