Azure Event Hubs 单事件检查点机制与同消费组消费者负载异常问题问询

问题1：部分消费者更新检查点是否会导致其他消费者的事件无法消费 #

不会。
Azure Event Hub的检查点是按分区独立存储和更新的，不存在消费组全局统一的检查点。每个消费者仅持有自己被分配到的分区的所有权，调用UpdateCheckpointAsync时，只会更新自身持有分区的最新消费偏移量，完全不影响其他消费者持有的分区的检查点状态。
就算C先完成更新，A、B持有的分区检查点仍然停留在各自上次更新的位置，后续A、B处理完事件后可正常更新对应分区的检查点。就算后续发生重平衡或者消费者重启，A、B负责的分区仍然会从该分区已记录的检查点位置开始消费，不会跳过未处理的事件1、2。

问题2：双消费者实例仅单实例消费的原因排查 #

你遇到的现象可从以下几个方向排查：

• 确认消费端是否使用了EventProcessorClient：只有基于处理器的消费模式才会自动执行负载均衡、分区分配和重平衡逻辑，如果直接使用底层Receiver API手动指定分区消费，不会触发自动分配，会出现单实例消费全部分区的情况。
• 确认两个实例的消费组配置完全一致：如果两个实例不小心配置了不同的消费组，相当于两个独立的消费者，会各自持有全部分区的所有权，导致只有一个实例能拉到消息。
• 确认两个实例共用同一个检查点存储：如果两个实例的检查点存储（通常为Azure Blob容器）配置不一致，无法同步分区所有权状态，会导致先启动的实例抢占全部分区的所有权。
• 确认测试消息是否均匀分布到所有分区：如果发送消息时指定了固定的分区键或分区ID，所有消息会被写入同一个分区，此时只有持有该分区的消费者会输出日志，另一个实例分到的分区无数据自然不会有消费记录。
• 预留足够的重平衡等待时间：EventProcessorClient启动后需要10~30秒的协商时间完成分区分配，建议两个实例全部启动后等待1分钟再发送测试消息，避免重平衡未完成导致的分配不均。

实验用查询语句 #

traces
| where message == "Event received"
| summarize count() by bin(timestamp,1s), cloud_RoleInstance
| render timechart 

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