你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
通过事件中心进行缩放
有两个因素会影响通过事件中心进行的缩放。
- 吞吐量单位（标准层）或处理单位（高级层）
- 分区
吞吐量单位
事件中心的吞吐量容量由“吞吐量单位”控制。 吞吐量单位是预先购买的容量单位。 单个吞吐量单位是指：
- 流入量：最高每秒 1 MB，或每秒 1000 个事件（以先达到的限制为准）。
- 流出量：最高每秒 2 MB，或每秒 4096 个事件。
超出所购吞吐量单位的容量时，流入量受限，事件中心将引发 ServerBusyException。 流出量不会生成限制异常，但仍受限于所购吞吐量单位的容量。 如果收到发布速率异常或者预期看到更高的出口，请务必检查为命名空间购买的吞吐量单位数量。 可以在 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，请参阅配置处理单位。
注意
若要详细了解配额和限制，请参阅 Azure 事件中心 - 配额和限制。
分区
事件中心将发送到事件中心的事件序列组织到一个或多个分区中。 当较新的事件到达时，它们将添加到此序列的末尾。
可以将分区视为提交日志。 分区可保存包含以下信息的事件数据：
- 事件的正文
- 描述事件的用户定义的属性包
- 元数据（如分区中的偏移量、流序列中的编号）
- 接受它的服务端时间戳
使用分区的优势
事件中心旨在帮助处理量较大的事件，分区通过两种方式对此提供帮助：
- 即使事件中心是 PaaS 服务，但其下面也存在物理现实。 维护保留事件顺序的日志要求将这些事件保存在基础存储及其副本中，这会导致此类日志存在吞吐量上限。 通过使用分区，可以将多个并行日志用于同一个事件中心，从而使可用的原始输入输出 (IO) 吞吐容量倍增。
- 你自己的应用程序必须能够及时处理要发送到事件中心的事件量。 它可能很复杂，并且需要大量的横向扩展并行处理容量。 用于处理事件的单个进程的容量有限，因此需要多个进程。 分区是解决方案为这些进程供给容量的一种方式，它们还能确保每个事件都有一个明确的处理所有者。
分区数
分区数在创建事件中心时指定。 该数值必须介于 1 和每个定价层允许的最大分区数之间。 有关每个层的分区计数限制，请参阅此文。
建议在特定事件中心的应用程序峰值负载期间，至少选择你预期需要的分区数。 对于高级层和专用层以外的层，创建事件中心后无法更改其分区计数。 对于高级或专用层中的事件中心，可以在创建后增加分区计数，但不能减少分区计数。 当分区键到分区的映射发生更改时，流在分区之间的分布也会发生更改，因此如果应用程序中事件的相对顺序很重要，你应该尽力避免此类更改。
将分区数设置为允许的最大值很有吸引力，但请始终记住，事件流需要进行结构化，这样你才能真正利用多个分区。 如果需要跨所有事件或仅少数几个子流保持绝对顺序，则你可能无法利用多个分区。 而且，多个分区会使处理端更加复杂。
在定价方面，事件中心中具有多少个分区并不重要。 这取决于命名空间或专用群集的定价单位数量（标准层为吞吐量单位 (TU)、高级层为处理单位 (PU)、专用层为容量单位 (CU)）。 例如，当命名空间设置为 1 TU 容量时，具有 32 个分区或 1 个分区的标准层的事件中心会产生完全相同的费用。 此外，你可以缩放命名空间的 TU 或 PU 或者专用群集的 CU，而不管分区计数如何。
由于分区是一种数据组织机制，支持以并行方式发布和使用数据。 我们建议均衡缩放单位（标准层的吞吐量单位、高级层的处理单位或专用层的容量单位）和分区，以实现最佳缩放。 通常情况下，建议将每个分区的最大吞吐量设置为 1 MB/秒。 因此，计算分区数的一项经验规则是将最大预期吞吐量除以 1 MB/秒。 例如，如果用例需要 20 MB/秒，则建议至少选择 20 个分区来实现最佳吞吐量。
但如果已有一个模型，其中的应用程序与特定分区存在相关性，则增加分区数量可能无用。 有关详细信息，请参阅可用性和一致性。
事件到分区的映射
可以使用分区键将传入事件数据映射到特定分区，以便进行数据组织。 分区键是发送者提供的、要传递给事件中心的值。 该键通过静态哈希函数进行处理，以便分配分区。 如果在发布事件时未指定分区键，则会使用循环分配。
事件发布者只知道其分区密钥，而不知道事件要发布到的分区。 键与分区的这种分离使发送者无需了解有关下游处理的过多信息。 每个设备或用户的唯一标识就可以充当一个适当的分区键，但是，也可以使用其他属性（例如地理位置），以便将相关的事件分组到单个分区中。
通过指定分区键，可使相关事件保持在同一分区中，并按其到达的确切顺序排列。 分区键是派生自应用程序上下文并标识事件之间的相互关系的字符串。 分区键标识的事件序列是一个流。 分区是针对许多此类流的多路复用日志存储。
注意
尽管你可以直接向分区发送事件，但我们不建议这样做，尤其是保持高可用性至关重要时。 这种做法会将事件中心的可用性降级到分区级别。 有关详细信息，请参阅可用性和一致性。
后续步骤
访问以下链接可以了解有关事件中心的详细信息：