Azure Event Hubs跨分区入口流量分配机制及负载均衡咨询

基础前提回顾 #

• 分区数量不影响定价，成本由标准层吞吐量单元（TU）、高级层**处理单元（PU）或专用层容量单元（CU）**的数量决定。例如1个TU的命名空间，无论Event Hub配置1个还是32个分区，成本完全一致。
• 分区是实现事件并行收发的核心机制，为达到最优吞吐量，需平衡扩展单元与分区数量：通常单分区建议最大处理1 MB/s吞吐量，因此20 MB/s的入口流量需至少配置20个分区。

核心流量分配逻辑 #

1. 使用分区键的场景

指定分区键时，Event Hubs通过哈希算法将相同分区键的事件固定映射到同一分区，但流量分配并非严格均等：

• 哈希映射关系是固定的，若不同分区键对应的事件量差异极大（比如某几个键的流量占比远超其他），对应分区的负载会远超1 MB/s，其余分区则可能处于低负载状态。
• 只有当所有分区键的流量完全均匀时，各分区才会接近1 MB/s的负载，但实际业务中几乎无法实现这种理想状态。
• 高吞吐量场景下，若某分区因哈希映射出现过载，会触发该分区的限流，直接影响对应分区键的事件写入。此时需调整分区键设计（比如拆分热点键）来平衡负载。

2. 不使用分区键或指定分区ID的场景

• 不指定分区键：Event Hubs采用轮询（Round-Robin）策略分配事件，长期来看各分区负载会保持均衡。需注意，轮询是基于事件批次而非单个事件，若批次大小差异较大，短时间内可能出现个别分区流量略高的情况，但整体均衡性不受影响。
• 指定分区ID：事件会直接写入指定分区，流量完全由业务写入逻辑决定，Event Hubs不会进行负载均衡。若持续向单个分区写入超过1 MB/s的流量，该分区会触发限流，而其他分区则处于空闲状态。

高流量多分区场景的关键注意事项 #

• 扩展单元的吞吐量是全局阈值：比如1个TU对应全局1 MB/s入口+1 MB/s出口吞吐量，即便有20个分区，总流量也不能超过TU的全局上限，同时单分区流量需控制在1 MB/s以内，否则会触发单分区限流。
• 若出现分区负载不均，除调整分区键或写入策略外，可通过增加扩展单元提升全局吞吐量，但单分区1 MB/s的建议上限仍需遵守。

内容的提问来源于stack exchange，提问作者TheDaveJay