Масштабирование с помощью концентраторов событий

Существует два фактора, влияющие на масштабирование с помощью Центров событий.

• Единицы пропускной способности (уровень "Стандартный") или блоки обработки (уровень "Премиум")
• Разделы

Единицы пропускной способности

Единицы пропускной способности управляют пропускной способностью концентраторов событий. Единицы пропускной способности — это предварительно приобретенные единицы емкости. Одна единица пропускной способности предоставляет следующие возможности:

• Входящий трафик: до 1 МБ в секунду или 1000 событий в секунду (в зависимости от того, что происходит первым).
• Исходящий трафик: до 2 МБ в секунду или 4096 событий в секунду.

При превышении емкости приобретенных единиц пропускной способности входящий трафик регулируется, а центры событий вызывают событие EventHubsException со значением причины ServiceBusy. Исходящий трафик не создает исключения при ограничении скорости, но он по-прежнему не может превышать емкость приобретенных единиц пропускной способности. Если вы получаете исключения по частоте публикации или ожидаете более высокий исходящий трафик данных, проверьте, сколько единиц пропускной способности вы приобрели для пространства имен. Вы можете управлять единицами пропускной способности на странице масштабирования пространств имен в портале Azure. Вы также можете программно управлять единицами пропускной способности с помощью API Центров событий.

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

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

• скорости входящего трафика данных превышают установленные единицы пропускной способности;
• скорости запросов исходящего трафика данных превышают установленные единицы пропускной способности.

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

Дополнительные сведения о функции автоинфляции см. в разделе "Автоматическое масштабирование единиц пропускной способности".

Процессорные блоки

Центры событий ценовой категории «Премиум» обеспечивают превосходную производительность и лучшую изоляцию в управляемой многопользовательской среде PaaS. Ресурсы ценовой категории «Премиум» изолированы на уровне ЦП и памяти, поэтому рабочая нагрузка каждого клиента выполняется изолированно. Этот контейнер ресурса называется блоком обработки (PU). Вы можете приобрести 1, 2, 4, 6, 8, 10, 12 или 16 единиц обработки данных для каждого пространства имен Центров событий Premium.

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

Например, пространство имен Event Hubs Premium с одним обработающим блоком и одним концентратором событий (100 разделов) может примерно предложить базовую емкость ~5–10 МБ/с входящего трафика и 10–20 МБ/с исходящего трафика для рабочих нагрузок AMQP или Kafka.

Дополнительные сведения о настройке PUS для пространства имен уровня "Премиум" см. в разделе "Настройка единиц обработки".

Примечание.

Дополнительные сведения о квотах и ограничениях см. в Центрах событий Azure— квотах и ограничениях.

Разделы

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

Раздел можно рассматривать как журнал фиксации. Разделы содержат данные о событиях, включающие следующие сведения:

• Содержимое события
• Определяемый пользователем контейнер свойств, описывающий событие
• Метаданные, такие как смещение в разделе, номер в последовательности потока
• Метка времени на стороне службы, в которой она была принята

Преимущества использования секций

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

• Несмотря на то, что Центры событий — это служба PaaS, под ней есть физическая реальность. Сохранение журнала, сохраняющего порядок событий, требует, чтобы эти события хранились вместе в базовом хранилище и ее репликах, что приводит к потолку пропускной способности для такого журнала. Секционирование позволяет использовать несколько параллельных журналов для одного концентратора событий и, таким образом, увеличивает доступную пропускную способность ввода-вывода.
• Ваши приложения должны справляться с обработкой объема событий, отправляемых в концентратор событий. Это может быть сложно и требует значительных ресурсов для масштабной, параллельной обработки. Емкость одного процесса обработки событий ограничена, поэтому вам требуется несколько процессов. Разделы — это способ, как ваше решение распределяет эти процессы и при этом заботится о том, чтобы у каждого события был четкий ответственный за обработку.

Количество разделов

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

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

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

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

Когда речь идет о ценообразовании, не важно, сколько разделов находится в концентраторе событий. Это зависит от количества единиц ценообразования (единиц пропускной способности для стандартного уровня, единиц обработки для уровня "Премиум" и единиц мощности для уровня "Выделенный") для пространства имен или выделенного кластера. Например, концентратор событий стандартного уровня с 32 секциями или с одной секцией влечет за собой одинаковую стоимость, если пространство имен имеет вместимость в один TU. Кроме того, можно масштабировать единицы транзакций (TUs) или единицы процесса (PUs) в вашем пространстве имен или единицы вычислительной мощности (CUs) в выделенном кластере независимо от количества разделов.

Раздел — это механизм организации данных, который обеспечивает параллельную публикацию и использование. Хотя она поддерживает параллельную обработку и масштабирование, общая емкость все равно ограничена выделением на масштабирование пространства имен. Балансируйте единицы масштабирования (единицы пропускной способности для стандартного уровня, единицы обработки для уровня "Премиум" или единицы емкости для выделенного уровня) и секции для достижения оптимального масштаба.

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

• Стандартный уровень: 1 МБ/с входящего трафика и около 2 МБ/с исходящего трафика на секцию.
• Уровни "Премиум" и "Выделенные": ~1–2 МБ/с входящего трафика и ~2–5 МБ/с исходящего трафика на раздел.

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

Разделы также задают предел для параллелизации запросов. Принцип работы потолка зависит от типа потребителя:

• Эпохальные (эксклюзивные) потребители — используются EventProcessorClient (.NET, Java) и EventHubConsumerClient (Python, JavaScript), что является рекомендуемым шаблоном для рабочих нагрузок AMQP. Только один потребитель эпохи может принадлежать заданной секции в группе потребителей одновременно. Если развертывать больше экземпляров процессора, чем разделов, дополнительные экземпляры не назначаются ни одному разделу и простаивают до тех пор, пока существующий владелец не освободит раздел. Если новый потребитель эпохи подключается к более высокому уровню владельца, служба отключает текущего владельца с ошибкой ConsumerDisconnected , и новый потребитель берет на себя.
• Потребители без эпохи — до 5 потребителей могут одновременно считывать один раздел в группе потребителей. Каждый получатель видит те же самые события (разветвление), поэтому этот режим не увеличивает пропускную способность обработки на партицию. Подключение потребителя эпохи к секции отключает всех потребителей, не относящихся к эпохе, в этой секции.
• Потребители Kafka — потребители Kafka используют протокол координации группы (group.id) вместо эпох AMQP, но модель владения секциями эквивалентна: каждая секция назначается ровно одному члену потребителя в группе потребителей одновременно. Когда новый член присоединяется или существующий член покидает, группа перебалансирует и перераспределяет назначения секций. Если потребителей больше, чем разделов, избыточные члены не получают назначений и остаются неактивными, до тех пор, пока следующая перебалансировка не освободит раздел. Чтобы уменьшить ненужные перебалансировки, вызываемые временными отключениями, задайте уникальный идентификатор group.instance.id для каждого экземпляра потребителя (статическое членство группы).

На практике число разделов равно максимальному количеству параллельных потребителей на группу потребителей независимо от того, используете ли вы потребителей AMQP epoch или потребителей Kafka. Учитывайте это количество секций при планировании масштабирования.

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

Сопоставление событий с разделами

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

Издателю событий известен только ключ раздела, но не сам раздел, в который публикуются события. Благодаря разделению ключа и раздела отправителю не нужно знать слишком много о последующей обработке. Уникальный идентификатор устройства или пользователя является хорошим ключом раздела, но другие атрибуты, такие как географическое положение, также можно использовать для объединения связанных событий в один раздел.

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

Примечание.

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

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

Дополнительные сведения о центрах событий см. в следующих статьях:

• Автоматическое масштабирование единиц пропускной способности для стандартного уровня пространства имен
• Настройка блоков обработки для пространства имен уровня "Премиум"