使用官方SDK并行消费Azure Event Hub时消费者负载不均问题排查

1. Event Processor Client默认负载均衡策略问题：默认使用Greedy贪心分配策略，先启动的实例会一次性抢占所有可用分区，默认的负载均衡更新间隔长达30秒，分区所有权过期时间也更长，如果你的测试消息在负载均衡触发二次分配前就已经被第一个实例消费完成，就会出现只有单实例消费的现象。
2. 测试流程时序问题：如果先写入测试消息再启动消费者实例，第一个启动的实例会立刻开始消费所有分区的消息，不等第二个实例完成启动、分区分配完成，10000条消息就已经消费完毕，自然看不到两个实例同时消费的重叠时段。
3. 过频的检查点操作虽然不是核心原因，但会额外增加存储交互开销，拖慢消费逻辑，间接放大前两个问题的影响。

代码配置调整 #

• 显式配置EventProcessorClient的负载均衡参数，改用均衡分配策略，缩短负载均衡触发间隔：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    // 新增处理器配置
    var processorOptions = new EventProcessorClientOptions
    {
        // 改用均衡分配策略，会在多实例间平均分配分区
        LoadBalancingStrategy = LoadBalancingStrategy.Balanced,
        // 缩短负载均衡检查间隔，默认30秒，调整为5秒
        LoadBalancingUpdateInterval = TimeSpan.FromSeconds(5),
        // 缩短分区所有权过期时间，默认30秒，调整为10秒
        PartitionOwnershipExpirationInterval = TimeSpan.FromSeconds(10)
    };

    _processor = new EventProcessorClient(_storageClient, _consumerGroup, _hubConnection, _eventHubName, processorOptions);
    _processor.ProcessEventAsync += ProcessEventHandler;
    _processor.ProcessErrorAsync += ProcessErrorHandler;

    await _processor.StartProcessingAsync(stoppingToken);
}

• 调整检查点更新逻辑，不要每条消息都更新检查点，降低不必要的存储IO开销，可按消息计数或时间间隔触发：

// 类内部定义计数器
private int _eventCount = 0;
private const int CheckpointThreshold = 100;

internal async Task ProcessEventHandler(ProcessEventArgs eventArgs)
{
    _logger.LogTelemetry("Event received");
    _eventCount++;

    // 每处理100条更新一次检查点
    if (_eventCount >= CheckpointThreshold)
    {
        await eventArgs.UpdateCheckpointAsync(eventArgs.CancellationToken);
        _eventCount = 0;
    }
}

测试流程调整 #

• 先启动所有消费者实例，等待10-15秒确保分区分配完成后，再写入测试消息。
• 若仍看不到并行消费，可适当增加测试消息量，或在消费逻辑中加入毫秒级的模拟业务延迟，拉长消费时间窗口，确保两个实例都有足够时间拿到分区并执行消费。

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