单个Azure Event Hub命名空间下如何处理多实体消息数据？

首先直接回答你提出的分区ID映射实体的方案：该方案在当前场景下是可行的，但存在一定限制，你可以结合业务实际需求选择更适配的方案。

方案1：使用partitionId直接映射实体（你提出的方案） #

Azure Event Hub基础层单实例最高支持创建32个分区，刚好可以满足你30个实体的映射需求，对应规则如下：

partitionId[1]: Entity 1
partitionId[2]: Entity 2
...
partitionId[30]: Entity 30

优势 #

• 天然保证同一实体的消息严格按生产顺序消费，不需要额外做排序处理
• 逻辑简单，不需要对消息做额外打标处理

限制 #

• Event Hub分区数量创建后不可修改，后续如果新增实体没有冗余分区可用，只能重建Event Hub
• 分区本身是Event Hub用来做吞吐量水平扩展的资源，按实体绑定分区会浪费扩展能力，单个实体流量突增时无法通过多分区分摊流量
• 下游如果只需要订阅部分实体，仍然需要拉取全部分区的消息自行过滤，会浪费带宽和消费端算力

方案2：单Event Hub + 自定义属性打标（更推荐的通用方案） #

你只需要创建1个Event Hub，发送消息时给每条消息添加自定义属性，比如EntityId，值为对应实体的唯一标识，下游消费时根据自身需求过滤指定EntityId的消息即可。

优势 #

• 灵活度极高，后续新增实体不需要修改Event Hub的任何配置
• 分区数量可以根据整体吞吐量需求设置，不需要和实体数量绑定，资源利用率更高
• 如果使用Kafka协议接入Event Hub，还可以开启服务端过滤能力，直接由服务端筛选符合要求的消息推送给消费端，减少无效数据传输

方案3：实体分组映射Event Hub（兼顾隔离性的方案） #

你可以将30个实体按业务域、消费方归属、流量量级分成最多10组，每组对应一个Event Hub，组内的实体仍然用自定义属性打标区分。

优势 #

• 刚好可以用完单个命名空间最多10个Event Hub的配额，不需要额外创建命名空间
• 不同业务线的消息物理隔离，消费端可以只订阅自己需要的Event Hub，大幅减少过滤的算力开销

选型建议 #

• 如果你的30个实体每个都要求严格的消息生产顺序，且未来半年内没有新增实体的计划，可以选择你提出的分区映射方案
• 如果后续存在新增实体的可能，或者不需要全局严格消息顺序，优先选择方案2或方案3，更符合Event Hub的设计逻辑，可扩展性更强

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