Azure EventHub: контрольные точки лучшие практики в C# EventProcessorClient

Question

В соответствии с документацией EventProcessorClient рекомендуется использовать потоки EventHub:

EventProcessorClient должен использоваться для чтения событий из всех разделов в производственный сценарий, так как он предлагает гораздо более надежную работу с более высокой пропускной способностью.

EventProcessorClient позволяет обновлять смещение потребителя только внутри обработчика сообщений, т.е. для каждого сообщения, что-то вроде:

var eventProcessorClient = new EventProcessorClient(...);
eventProcessorClient.ProcessEventAsync += ProcessEventHandler;
eventProcessorClient.StartProcessingAsync(stoppingToken);

...

static async Task ProcessEventHandler(ProcessEventArgs eventArgs)
{
    Console.WriteLine("Received event: {0}", Encoding.UTF8.GetString(eventArgs.Data.Body.ToArray()));
    await eventArgs.UpdateCheckpointAsync(eventArgs.CancellationToken);
}

В то же время в документации для eventhub :

Обновление после каждого успешно обработанного события может повлиять на производительность и стоимость, так как запускает операцию записи в базовое хранилище контрольных точек. , Кроме того, контрольная точка каждого отдельного события указывает на шаблон обмена сообщениями в очереди, для которого очередь шины интеграции может быть лучшим вариантом, чем концентратор событий. Идея Event Hubs заключается в том, что вы получаете «хотя бы раз» доставку в больших масштабах.

Как эффективно обновить контрольную точку раздела? Должен ли я использовать клиент Kafka вместо Azure.Messaging.EventHubs?

Answer 1

Проверка после каждого сообщения не очень хорошая идея. Я бы порекомендовал вам контрольную точку после каждой партии сообщений, которую вы обработали, например, после каждых 50 сообщений (я думаю, что число зависит от того, сколько сообщений вы обрабатываете и т. Д. c ...)

Кроме того, вы должны подумать о том, как вы справляетесь с сообщениями, которые обрабатываются дважды. Например, может произойти сбой вашего EventProcessorClient, что означает, что он возобновит чтение из EventHub с последней позиции контрольной точки. В этом случае вы прочитаете некоторые сообщения, которые вы, возможно, уже обработали. Так что в этом случае вам нужно подумать о механизме, который может справиться с этим.