Должен ли я помещать свои события в очередь после получения их от Azure Event Hub?

Question

В настоящее время я разрабатываю приложение на Azure, которое использует Azure Event Hub. В основном я отправка сообщений (или я должен сказать, событий) к концентратору событий из веб-API, и у меня есть два слушателя:

• задача Стрим Analytics для анализа в реальном времени
• стандартный работник роль, которая вычисляет некоторые вещи на основе полученных событий, а затем сохраняет их в базе данных Azure SQL (это лямбда-архитектура).

В настоящее время я использую библиотеку EventProcessorHost для извлечения своих событий из Event Hub внутри моей рабочей роли.

Я пытаюсь найти некоторые рекомендации по использованию концентратора событий (немного сложнее использовать концентраторы событий, чем очереди служебных шин, то есть потоковая передача сообщений), и я обнаружил, что некоторые люди говорят I не должен делать много обработки после извлечения EventData событий из моего Event Hub.

В частности:

• http://blogs.msdn.com/b/servicebus/archive/2015/01/16/event-processor-host-best-practices-part-1.aspx

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

• http://blogs.msdn.com/b/musings_on_alm_and_software_development_processes/archive/2014/09/03/azure-event-hubs-queues-and-workers.aspx

Автор данной статьи добавил очередь между концентратором событий и работника роли (это не ясно из комментариев, если это действительно требуется или нет).

Так что вопрос: я должен делать всю обработку материала непосредственно после того, как концентратор событий (т.е. внутри ProcessEventsAsnyc метода моей IEventProcessor реализации), или я должен использовать очередь между концентратором события и обрабатывающий материал?

Любая рекомендация о том, как правильно потреблять события от концентратора событий, будет оценена, документация в настоящее время немного ... отсутствует.

Answer 1

Это относится к категории вопросов, ответ на которые будет гораздо более очевидным после того, как источник EventProcessorHost станет доступным, и мне сказали, что это произойдет.

Короткий ответ заключается в том, что вам не нужно использовать очередь; однако, я бы сохранил время ProcessEventsAsync, чтобы вернуть задачу относительно короткой.

Хотя этот совет звучит так же, как у first article, ключевое различие заключается в том, что настало время вернуть задачу, а не время завершения задачи. Мое предположение заключалось в том, что ProcessEventsAsync вызывается в потоке, используемом для EventProcessorHost для других целей.В этом случае вам нужно быстро вернуться, чтобы другая работа продолжалась; эта работа может вызвать ProcessEventsAsync для другого раздела (но мы не будем знать, что без отладки я не счел нужным делать или читать код, когда он доступен).

Я обрабатываю отдельную нить на раздел, пропуская весь IEnumerable из ProcessEventsAsync. Это контрастирует с тем, чтобы вытащить все элементы из IEnumerable и помещать их в очередь для потока обработки. Другой поток завершает задачу, возвращенную ProcessEventsAsync, когда она завершила обработку сообщений. (Я фактически передаю свой поток обработки только один IEnumerable, который скрывает детали ProcessEventsAsync, объединяя куски вместе и завершая задачу, если это необходимо при вызове MoveNext).

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

Ввод всех сообщений в очередь внутри ProcessEventsAsync не bad это просто не самый эффективный способ передать кусок событий в другой поток.

Если вы решили поместить события в очередь (ИЛИ иметь очередь вниз по потоку в вашем коде обработки) и выполнить задачу для партии, вы должны убедиться, что вы ограничиваете количество элементов, которые у вас остались в коде/чтобы избежать нехватки памяти в случае, когда EventHub предоставляет вам элементы быстрее, чем ваш код может обрабатывать их из-за всплеска трафика.

Примечание для Java EventHub пользователей 2016-10-27: Так как это пришло мое внимание там this description описания того, как onEvents называется, в то время как onEvents медлительность не будет трагедией, так как это на нитку за перегородкой, ее скорость появляется, чтобы повлиять на скорость, с которой получена следующая партия. Таким образом, в зависимости от того, насколько вы заботитесь о достаточно низкой задержке, здесь может быть относительно важным для вашего сценария.