Блог

У меня есть концентратор событий и подключенная к нему функция Azure. С небольшими объемами данных все работает хорошо, но когда я протестировал его на 10 000 событиях, я получил очень странные результаты. В целях тестирования я отправляю в концентратор событий номера от 0 до 9999 и регистрирую данные в Application insights и в служебной шине. Для первого теста я вижу в Azure, что концентратор получил ровно 10 000 событий, но служебная шина и AI получили все сообщения от 0 до 4500 и каждое второе сообщение после 4500 (так что он потерял около 30%). Во втором тесте я получил все сообщения от 0 до 9999, но каждое второе сообщение между 3500 и 3200 было продублировано. Я хотел бы получить все сообщения один раз, что я сделал не так?

 public async Task Run([EventHubTrigger("%EventHubName%", Connection = "AzureEventHubConnectionString")] EventData[] events, ILogger log)
    {
        int id = _random.Next(1, 100000);
        _context.Log.TraceInfo("Started. Count: "   events.Length   ". "   id); //AI log
        foreach (var message in events)
        {
            //log with ASB
            var mess = new Message();
            mess.Body = message.EventBody.ToArray();
            await queueClient.SendAsync(mess);
        }
        _context.Log.TraceInfo("Completed. "   id); //AI log
    }
 

Используя события EventData [], вы считываете события из концентратора в пакетном режиме, поэтому вы видите обработку X событий одновременно, а затем в следующие секунды обрабатываете следующую партию.

Вместо EventData[] используйте просто EventData.

При отправке событий в концентратор убедитесь, что все события отправляются с одним и тем же ключом раздела, если вы хотите попробовать пакетную обработку, в противном случае они могут быть разделены на несколько разделов в зависимости от TU (единиц пропускной способности), PU (единиц обработки) и CU (единиц емкости).

Выход: До 2 МБ в секунду или 4096 событий в секунду.

Обратитесь к этому документу.

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

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

Первое, что следует знать,-это то, что время между моментом публикации события и моментом, когда оно доступно в разделе для чтения, не является детерминированным. Когда операция публикации завершается, брокер концентраторов событий подтверждает получение событий и берет на себя ответственность за обеспечение их сохранения в нескольких репликах и доступности в определенном разделе. Однако это не является гарантией того, что событие может быть немедленно прочитано.

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

Что касается дублирования, важно знать, что концентраторы событий предоставляют гарантию «по крайней мере один раз»; ваше приложение-потребитель должно ожидать некоторых дубликатов и должно уметь обрабатывать их так, как это подходит для вашего сценария приложения.

Функции Azure используют набор процессоров событий в своей инфраструктуре для чтения событий. Процессоры сотрудничают друг с другом, чтобы разделить работу и распределить ответственность за разделы между ними. Поскольку сотрудничество осуществляется с использованием хранилища в качестве посредника для синхронизации, при увеличении или уменьшении масштаба экземпляров происходит наложение прав собственности на разделы, в течение которого увеличивается вероятность дублирования.

Функции принимают решение о масштабировании на основе количества событий, которые, по их мнению, ожидают чтения в разделах. В случае вашего теста, если шаблон публикации быстро увеличивается и функции видят, что «отставание по событиям» растет до такой степени, что возникает необходимость масштабирования на несколько экземпляров, вы увидите больше дублирования, чем в противном случае, в течение 10-30 секунд, пока владение разделами не нормализуется. Чтобы смягчить это, использование подхода постепенного увеличения скорости публикации в течение 1-2 минут может помочь сгладить масштабирование и уменьшить (но не устранить) дублирование.