Масштабирование приложения обработки
Чтобы масштабировать ваше приложение обработки событий, можно запустить несколько экземпляров приложения и распределять (балансировать) нагрузку между ними. В более ранних версиях балансировать нагрузку между несколькими экземплярами программы и создавать события контрольных точек при их получении можно было с помощью EventProcessorHost. В более новых версиях (начиная с версии 5.0) то же самое делается с помощью EventProcessorClient (.NET и Java) или EventHubConsumerClient (Python и JavaScript).
Примечание.
Масштабирование в Центрах событий базируется на идее секционированных потребителей. В отличие от шаблона конкурирующих потребителей, секционированный потребительский шаблон обеспечивает высокий уровень масштабирования путем удаления конфликтного узкого места и упрощения сквозного параллелизма.
Пример сценария
В качестве примера рассмотрим компанию по обеспечению безопасности дома, которая отслеживает 100 000 домов. Каждую минуту она получает данные от различных датчиков, таких как датчики движения, датчики открытия дверей и окон, датчики разбития стекла и т. п., установленных в каждом из домов. Компания предоставляет веб-сайт для жителей, чтобы наблюдать за деятельностью своего дома почти в реальном времени.
Каждый датчик отправляет данные в концентратор событий. Концентратор событий настроен на 16 секций. В конечном итоге нужен механизм, который может считывать эти события, консолидировать их и выгружать агрегат в BLOB-объект хранилища, который затем проецируется на удобную для пользователя веб-страницу.
При создании потребителя в распределенной среде сценарий должен удовлетворять следующие требования:
- Масштаб. Создайте несколько потребителей и каждый потребитель возьмет на себя ответственность за чтение нескольких секций Центров событий.
- Балансировка нагрузки. Изменяйте количество потребителей динамически. Например, при добавлении нового типа датчика в каждый дом (например, детектора угарного газа) увеличивается число событий. В этом случае оператор (человек) увеличивает число экземпляров потребителя. Затем пул потребителей может перебалансировать количество секций, которыми они владеют, для распределения нагрузки на вновь добавленных потребителей.
- Беспрепятственное возобновление в случае сбоев. Если у потребителя (потребитель А) происходит сбой (например, работа виртуальной машины, где размещается этот потребитель, аварийно завершается), другие пользователи могут выбирать секции, принадлежащие потребителю A, и продолжать работу. Кроме того, точка продолжения, называемая контрольной точкой или смещением, должна находиться в точке пересечения, в которой произошел сбой потребителя А, или немного раньше этого.
- Получение событий. В то время как предыдущие три точки занимаются управлением потребителем, также необходим код, который будет потреблять события и выполнять над ними осмысленные действия. Например, он может агрегировать их и выгружать в хранилище BLOB-объектов.
Обработчик событий или клиент-потребитель
Разрабатывать собственное решение для выполнения этих требований не нужно. Эту функциональность реализуют пакеты SDK Центров событий Azure. В пакетах SDK для .NET или Java используется клиент обработчика событий (EventProcessorClient
), а в пакетах SDK для Python и JavaScript используется EventHubConsumerClient
.
Для большинства рабочих сценариев рекомендуется использовать клиент обработчика событий для чтения и обработки событий. Клиенты обработчика событий могут работать совместно в контексте группы потребителей для заданного концентратора событий. Клиенты будут автоматически управлять распределением и балансировкой рабочей нагрузки по мере того, как в группе появляются новые доступные экземпляры или становятся недоступны имеющиеся.
Отслеживание владения секциями
Экземпляр обработчика событий обычно является владельцем событий из одной или нескольких секций и обрабатывает эти события. Владение секциями равномерно распределяется между всеми активными экземплярами обработчика событий, связанными с сочетанием концентратора событий и группы потребителей.
Каждому из обработчиков событий присваивается уникальный идентификатор, и он берет на себя владение секциями, добавляя или обновляя запись в хранилище контрольных точек. Все экземпляры обработчика событий периодически взаимодействуют с этим хранилищем, чтобы обновить собственное состояние обработки и узнать о других активных экземплярах. Затем эти данные используются для балансировки нагрузки между активными обработчиками.
Получение сообщений
При создании обработчика событий необходимо указать функции, обрабатывающие события и ошибки. Каждый вызов функции, обрабатывающей события, доставляет одно событие из определенной секции. Ответственность за обработку этого события лежит на вас. Если вы хотите гарантировать, что потребитель обработает каждое событие по меньшей мере однократно, вам следует написать собственный код с логикой выполнения повторных попыток. Но учитывайте при этом возможность получения поврежденных сообщений.
Рекомендуется производить обработку относительно быстро. Это означает, что объем обработки должен быть как можно меньшим. Если необходимо и выполнять запись в хранилище, и производить маршрутизацию, лучше использовать две группы потребителей и располагать двумя обработчиками событий.
Назначение контрольных точек
Назначение контрольных точек — это процесс, в ходе которого обработчик событий отмечает или фиксирует положение последнего успешно обработанного события в секции. Отметка контрольной точки обычно выполняется из функции, которая обрабатывает события, и выполняется посекционно в рамках группы потребителей.
Если обработчик событий отключается от секции, другой экземпляр может возобновить обработку этой секции с контрольной точки, которая ранее была зафиксирована последним обработчиком этой секции в данной группе потребителей. При подключении обработчик передает концентратору событий смещение, указывая, с какого положения нужно начать считывание. Таким образом назначение контрольных точек можно использовать и для того, чтобы отмечать события, как "выполненные" в нижележащих приложениях, и для обеспечения устойчивости в случае нарушения работы обработчика событий. Можно вернуться к предыдущим данным, указав в этом процессе назначения контрольных точек меньшую величину смещения.
Потокобезопасность и экземпляры процессора
По умолчанию функция, которая обрабатывает события, вызывается последовательно для определенной секции. Последующие сообщения и вызовы этой функции для той же секции ставятся в очередь "за кулисами", в то время как конвейер событий продолжает выполнение в фоновом режиме в других потоках. События из разных секций могут обрабатываться параллельно, при этом любое общее состояние, к которому осуществляется доступ из различных секций, должно быть синхронизировано.