Partilhar via

Adicionar partições dinamicamente a um hub de eventos (tópico Apache Kafka)

  • Artigo

O Event Hubs fornece transmissão de mensagens através de um padrão de consumidor particionado em que cada consumidor só lê um subconjunto específico, ou partição, do fluxo de mensagens. Este padrão permite um dimensionamento horizontal do processamento de eventos e fornece outras funcionalidades centradas nos fluxos que não estão disponíveis nas filas e nos tópicos. Uma partição é uma sequência ordenada de eventos mantida num hub de eventos. À medida que novos eventos chegam, eles são adicionados ao final desta sequência. Para obter mais informações sobre partições em geral, consulte Partições

Você pode especificar o número de partições no momento da criação de um hub de eventos. Em alguns cenários, talvez seja necessário adicionar partições após a criação do hub de eventos. Este artigo descreve como adicionar partições dinamicamente a um hub de eventos existente.

Importante

As adições dinâmicas de partições estão disponíveis apenas nas camadas premium e dedicada dos Hubs de Eventos.

Nota

Para clientes Apache Kafka, um hub de eventos mapeia para um tópico Kafka. Para obter mais mapeamentos entre Hubs de Eventos do Azure e Apache Kafka, consulte Mapeamento conceitual de Kafka e Hubs de Eventos

Atualizar a contagem de partições

Esta seção mostra como atualizar a contagem de partições de um hub de eventos de diferentes maneiras (PowerShell, CLI e assim por diante.).

PowerShell

Use o comando Set-AzEventHub PowerShell para atualizar partições em um hub de eventos.

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

CLI

Use o az eventhubs eventhub update comando CLI para atualizar partições em um hub de eventos.

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

Modelo do Resource Manager

Atualize o partitionCount valor da propriedade no modelo do Gerenciador de Recursos e reimplante o modelo para atualizar o recurso.

    {
        "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

Use a API (por exemplo, por meio da ferramenta kafka-topics CLI) para aumentar a AlterTopics contagem de partições. Para obter detalhes, consulte Modificando tópicos de Kafka.

Clientes de Hubs de Eventos

Vamos ver como os clientes dos Hubs de Eventos se comportam quando a contagem de partições é atualizada em um hub de eventos.

Quando você adiciona uma partição a um hub par existente, o cliente do hub de eventos recebe um MessagingException do serviço informando aos clientes que os metadados da entidade (entidade é seu hub de eventos e metadados são as informações da partição) foram alterados. Os clientes reabrirão automaticamente os links AMQP, que então pegarão as informações de metadados alteradas. Os clientes funcionam então normalmente.

Clientes remetentes/produtores

Os Hubs de Eventos fornecem três opções de remetente:

  • Remetente da partição – Neste cenário, os clientes enviam eventos diretamente para uma partição. Embora as partições sejam identificáveis e os eventos possam ser enviados diretamente para elas, não recomendamos esse padrão. Adicionar partições não afeta esse cenário. Recomendamos que você reinicie os aplicativos para que eles possam detetar partições recém-adicionadas.
  • Remetente da chave de partição – neste cenário, os clientes enviam os eventos com uma chave para que todos os eventos pertencentes a essa chave acabem na mesma partição. Nesse caso, o serviço faz hash da chave e roteia para a partição correspondente. A atualização da contagem de partições pode causar problemas fora de ordem devido à alteração de hash. Portanto, se você se preocupa com o pedido, certifique-se de que seu aplicativo consuma todos os eventos de partições existentes antes de aumentar a contagem de partições.
  • Remetente round-robin (padrão) – Nesse cenário, o serviço Hubs de Eventos round robins os eventos entre partições e também usa um algoritmo de balanceamento de carga. O serviço Hubs de Eventos está ciente das alterações na contagem de partições e enviará para novas partições em segundos após alterar a contagem de partições.

Clientes recetores/consumidores

Os Hubs de Eventos fornecem recetores diretos e uma biblioteca de consumidor fácil chamada Processador de Eventos.

  • Recetores diretos – Os recetores diretos ouvem partições específicas. Seu comportamento de tempo de execução não é afetado quando as partições são dimensionadas para um hub de eventos. O aplicativo que usa recetores diretos precisa cuidar de pegar as novas partições e atribuir os recetores de acordo.

  • Host do processador de eventos – Este cliente não atualiza automaticamente os metadados da entidade. Então, ele não pegaria no aumento da contagem de partições. Recriar uma instância do processador de eventos causará uma busca de metadados de entidade, que, por sua vez, criará novos blobs para as partições recém-adicionadas. Os blobs pré-existentes não serão afetados. Recomenda-se reiniciar todas as instâncias do processador de eventos para garantir que todas as instâncias estejam cientes das partições recém-adicionadas e que o balanceamento de carga seja tratado corretamente entre os consumidores.

    Se você estiver usando a versão antiga do SDK do .NET (WindowsAzure.ServiceBus), o host do processador de eventos removerá um ponto de verificação existente após a reinicialização se a contagem de partições no ponto de verificação não corresponder à contagem de partições buscada no serviço. Esse comportamento pode ter um impacto em seu aplicativo.

    Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, para que você não possa mais usar esse protocolo após 30 de setembro de 2026. Migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e recursos aprimorados, antes dessa data.

    Embora as bibliotecas mais antigas ainda possam ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, consulte o anúncio de aposentadoria de suporte.

Clientes Apache Kafka

Esta seção descreve como os clientes Apache Kafka que usam o ponto de extremidade Kafka dos Hubs de Eventos do Azure se comportam quando a contagem de partições é atualizada para um hub de eventos.

Os clientes Kafka que usam Hubs de Eventos com o protocolo Apache Kafka se comportam de forma diferente dos clientes de hub de eventos que usam o protocolo AMQP. Os clientes Kafka atualizam seus metadados uma vez a cada metadata.max.age.ms milissegundos. Você especifica esse valor nas configurações do cliente. As librdkafka bibliotecas também usam a mesma configuração. As atualizações de metadados informam os clientes sobre as alterações do serviço, incluindo o aumento da contagem de partições. Para obter uma lista de configurações, consulte Configurações do Apache Kafka para Hubs de Eventos.

Clientes remetentes/produtores

Os produtores sempre ditam que as solicitações de envio contêm o destino da partição para cada conjunto de registros produzidos. Assim, todo o particionamento de produção é feito no lado do cliente com a visão do produtor dos metadados do corretor. Assim que as novas partições forem adicionadas à visualização de metadados do produtor, elas estarão disponíveis para solicitações do produtor.

Clientes consumidores/recetores

Quando um membro do grupo de consumidores executa uma atualização de metadados e seleciona as partições recém-criadas, esse membro inicia um reequilíbrio do grupo. Os metadados do consumidor serão atualizados para todos os membros do grupo e as novas partições serão atribuídas pelo líder de reequilíbrio alocado.

Recomendações

  • Se você usa a chave de partição com seus aplicativos de produção e depende do hash de chave para garantir a ordenação em uma partição, adicionar partições dinamicamente não é recomendado.

    Importante

    Enquanto os dados existentes preservam a ordem, o hash de partição será quebrado para mensagens com hash depois que a contagem de partições for alterada devido à adição de partições.

  • A adição de partição a um tópico existente ou a uma instância de hub de eventos é recomendada nos seguintes casos:

    • Quando você usa o método padrão de envio de eventos
    • Estratégias de particionamento padrão Kafka, exemplo – Estratégia Sticky Assignor

Próximos passos

Para obter mais informações sobre partições, consulte Partições.