Балансировка нагрузки секции для обработки событий

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

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

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

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

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

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

Пользовательское приложение

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

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

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

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

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

Владение секцией

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

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

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

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

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

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

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

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

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

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

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

Следуйте этим рекомендациям при использовании хранилища BLOB-объектов Azure в качестве хранилища контрольных точек:

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

На странице учетной записи хранения в Azure Portal в разделе Blob service, убедитесь, что указанные настройки отключены.

• Иерархическое пространство имен
• Обратимое удаление BLOB-объекта
• Управление версиями

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

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

Связанный контент

Ознакомьтесь со следующими краткими руководствами.

• .NET Core
• Java
• Питон
• JavaScript