Динамическое добавление секций в концентратор событий (раздел Apache Kafka)

  • Статья

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

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

Внимание

Динамическое добавление разделов доступно только на уровне Премиум и Выделенный Центров событий.

Примечание.

Для клиентов Apache Kafka концентратор событий соответствует разделу Kafka. Другие сопоставления аналогичных компонентов можно найти в разделе Сопоставление понятий Kafka и концентратора событий.

Изменение числа секций

В этом разделе показано, как изменить число секций концентратора событий разными способами (PowerShell, CLI и т. д.).

PowerShell

Используйте команду Set-AzEventHub PowerShell для обновления секций в концентраторе событий.

Set-AzEventHub -ResourceGroupName MyResourceGroupName -Namespace MyNamespaceName -Name MyEventHubName -partitionCount 12

CLI

Чтобы изменить секции в концентраторе событий, используйте команду CLI az eventhubs eventhub update.

az eventhubs eventhub update --resource-group MyResourceGroupName --namespace-name MyNamespaceName --name MyEventHubName --partition-count 12

Шаблон Resource Manager

Чтобы изменить ресурс, задайте новое значение свойства partitionCount в шаблоне Resource Manager и повторно разверните этот шаблон.

    {
        "apiVersion": "2017-04-01",
        "type": "Microsoft.EventHub/namespaces/eventhubs",
        "name": "[concat(parameters('namespaceName'), '/', parameters('eventHubName'))]",
        "location": "[parameters('location')]",
        "dependsOn": [
            "[resourceId('Microsoft.EventHub/namespaces', parameters('namespaceName'))]"
        ],
        "properties": {
            "messageRetentionInDays": 7,
            "partitionCount": 12
        }
    }

Apache Kafka

Чтобы увеличить число секций, используйте API AlterTopics (например, через средство CLI kafka-topics). Дополнительные сведения см. в статье об изменении разделов Kafka.

Клиенты Центров событий

Давайте рассмотрим, как работают клиенты Центров событий при изменении числа секций в концентраторе событий.

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

Клиенты отправителя (производителя)

Концентраторы событий поддерживают три варианта отправителей.

  • Отправитель для секции — в этом сценарии клиенты отправляют события непосредственно в секцию. Секции можно идентифицировать и события можно отправлять напрямую в них, поэтому мы не рекомендуем использовать этот шаблон. Добавление секций никак не влияет на этот сценарий. Мы рекомендуем перезапустить приложения, чтобы они обнаружили новые секции.
  • Отправитель ключа секции — в этом сценарии клиенты отправляют события с ключом, чтобы все события с одним значением ключа записывались в одну секцию. При этом служба хэширует ключ и отправляет события в соответствующую секцию. Изменение числа секций может привести к проблемам нарушения порядка, так как структура хэширования также изменится. Таким образом, если упорядочение важно для вашего сценария, дождитесь обработки всех ожидающих событий в существующих секциях, прежде чем увеличивать число секций.
  • Отправитель с циклическим перебором (вариант по умолчанию) — в этом сценарии служба "Центры событий" отправляет события в разные секции поочередно, а также использует алгоритм балансировки нагрузки. Служба "Центры событий" получает сведения о числе секций через несколько секунд после его изменения, и сразу начинает отправку событий в новые секции.

Клиенты приемника (потребителя)

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

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

  • Узел обработчика событий — такой клиент не обновляет метаданные сущностей автоматически. Это означает, что он не узнает об увеличении числа секций. Повторное создание экземпляра обработчика событий приведет к получению метаданных сущности, что в свою очередь активирует создание новых BLOB-объектов для новых секций. Это никак не затронет существующие BLOB-объекты. Мы рекомендуем перезапустить все экземпляры обработчика событий, чтобы все экземпляры получили информацию о новых секциях и нормально работала балансировка нагрузки между потребителями.

    Если вы используете старую версию пакета SDK для .NET (WindowsAzure.ServiceBus), узел обработчика событий после перезапуска удаляет существующую контрольную точку, если число секций в этой контрольной точке не совпадает с числом секций, полученным от службы. Такое поведение может повлиять на работу приложения.

    30 сентября 2026 г. мы удалим библиотеки пакета SDK Служебная шина Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus и com.microsoft.azure.servicebus, которые не соответствуют рекомендациям по пакету SDK Azure. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.

    Хотя старые библиотеки по-прежнему могут использоваться после 30 сентября 2026 года, они больше не будут получать официальную поддержку и обновления от Майкрософт. Дополнительные сведения см. в объявлении о выходе на пенсию в службу поддержки.

Клиенты Apache Kafka

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

Поведение клиентов Kafka, которые работают со службой "Центры событий" по протоколу Apache Kafka, отличается от поведения клиентов концентратора событий, которые используют протокол AMQP. Клиенты Kafka обновляют свои метаданные через определенное число миллисекунд (metadata.max.age.ms). Это значение можно указать в конфигурациях клиента. Библиотеки librdkafka также используют эту конфигурацию. Обновление метаданных позволяет клиентам узнать об изменениях в службе, в том числе об увеличении количества секций. Список конфигураций можно получить в репозитории конфигураций Apache Kafka для службы "Центры событий"

Клиенты отправителя (производителя)

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

Клиенты приемника (потребителя)

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

Рекомендации

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

    Внимание

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

  • Добавление секции в существующий раздел или экземпляр концентратора событий рекомендуется в следующих случаях:

    • для отправки событий используется метод, установленный по умолчанию;
    • для секционирования используются стандартные стратегии Kafka, например StickyAssignor.

Следующие шаги

Дополнительные сведения о секциях см. в разделе Секции.