Масштабирование приложения обработки

3 мин

Чтобы масштабировать приложение обработки событий, можно запустить несколько экземпляров приложения и сбалансировать нагрузку между собой. В старых версиях EventProcessorHost позволял балансировать нагрузку между несколькими экземплярами программы и задавать контрольные точки при получении событий. В более новых версиях (5.0) EventProcessorClient (.NET и Java) или EventHubConsumerClient (Python и JavaScript) позволяет выполнять то же самое.

Заметка

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

Пример сценария

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

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

При проектировании потребителя в распределенной среде сценарий должен обрабатывать следующие требования:

Масштабирование: Создайте несколько потребителей, и каждый потребитель принимает на себя ответственность за чтение из нескольких разделов Центров событий.
Балансировка нагрузки: динамическое увеличение или уменьшение числа потребителей. Например, при добавлении нового типа датчика (например, детектора углеродного газа) в каждый дом увеличивается число событий. В этом случае оператор (человек) увеличивает число экземпляров потребителей. Затем пул потребителей может перебалансировать количество секций, которыми они владеет, чтобы поделиться нагрузкой с вновь добавленными потребителями.
Бесшовное возобновление после сбоев: Если потребитель (потребитель A) завершает работу сбоем (например, виртуальная машина, на которой размещён потребитель, внезапно падала), другие потребители могут взять на себя разделы, принадлежащие потребителю A и продолжить. Кроме того, точка продолжения, называемая контрольной точкой или смещением , должна находиться в точке, где произошел сбой у потребителя A , или немного ранее.
Использовать события: В то время как предыдущие три пункта имеют дело с управлением потребителем, должен быть код, чтобы использовать события и делать с ним что-то полезное. Например, агрегируйте данные и загрузите их в хранилище BLOB-объектов.

Обработчик событий или клиент-потребитель

Вам не нужно создавать собственное решение для удовлетворения этих требований. Пакеты SDK центров событий Azure предоставляют эту функцию. В пакетах SDK для .NET или Java используется клиент обработчика событий (EventProcessorClient), а в пакетах SDK Для Python и JavaScript используется EventHubConsumerClient.

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

Отслеживание владения разделами

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

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

Получение сообщений

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

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

Контрольная точка

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

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

Потокобезопасность и экземпляры процессоров

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