Condividi tramite

Aggiungere dinamicamente partizioni a un hub eventi (argomento Apache Kafka)

  • Articolo

Hub eventi fornisce il flusso dei messaggi tramite un modello di consumer partizionato in cui ogni consumer legge solo un subset specifico, o partizione, del flusso di messaggi. Questo modello offre la scalabilità orizzontale per l'elaborazione di eventi e fornisce altre funzionalità incentrate sui flussi che non sono disponibili in code e argomenti. Una partizione è una sequenza ordinata di eventi che viene mantenuta in un hub eventi. Man mano che arrivano, i nuovi eventi vengono aggiunti alla fine di questa sequenza. Per altre informazioni sulle partizioni in generale, vedere Partizioni

È possibile specificare il numero di partizioni al momento della creazione di un hub eventi. In alcuni scenari potrebbe essere necessario aggiungere partizioni dopo che è stato creato l'hub eventi. Questo articolo descrive come aggiungere partizioni in modo dinamico a un hub eventi esistente.

Importante

Le aggiunte dinamiche delle partizioni sono disponibili solo nei livelli Premium e dedicati di Hub eventi.

Nota

Per i client Apache Kafka, un hub eventi viene associato a un argomento Kafka. Per altre associati tra Hub eventi di Azure e Apache Kafka, vedere la sezione relativa all'associazione concettuale tra Kafka e Hub eventi

Aggiornare il numero di partizioni

Questa sezione illustra come aggiornare il numero di partizioni di un hub eventi in modi diversi (PowerShell, interfaccia della riga di comando e così via).

PowerShell

Usare il comando PowerShell Set-AzEventHub per aggiornare le partizioni in un hub eventi.

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

CLI

Usare il comando dell'interfaccia della az eventhubs eventhub update riga di comando per aggiornare le partizioni in un hub eventi.

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

Modello di Resource Manager

Aggiornare il valore della proprietà partitionCount nel modello di Resource Manager e ridistribuire il modello per aggiornare la risorsa.

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

Usare l'API AlterTopics (ad esempio, tramite l'interfaccia della riga di comando kafka-topics) per aumentare il numero di partizioni. Per informazioni dettagliate, vedere la sezione relativa alla modifica degli argomenti di Kafka.

Client di Hub eventi

Verrà ora esaminato il comportamento dei client di Hub eventi quando il numero di partizioni viene aggiornato in un hub eventi.

Quando si aggiunge una partizione a un hub pari esistente, il client dell'hub eventi riceve un MessagingException oggetto dal servizio che informa i client che i metadati dell'entità (entità è l'hub eventi e i metadati sono le informazioni sulla partizione) sono stati modificati. I client riapriranno automaticamente i collegamenti AMQP, che preleveranno le informazioni sui metadati modificati. I client quindi funzionano normalmente.

Client mittenti/producer

Hub eventi offre tre opzioni di mittente:

  • Mittente partizione: in questo scenario, i client inviano eventi direttamente a una partizione. Sebbene le partizioni siano identificabili e sia possibile inviarvi direttamente gli eventi, questo modello non è consigliato. L'aggiunta di partizioni non ha alcun effetto su questo scenario. Si consiglia di riavviare le applicazioni in modo che possano rilevare le partizioni appena aggiunte.
  • Mittente chiave di partizione: in questo scenario, i client inviano gli eventi con una chiave in modo che tutti gli eventi appartenenti a tale chiave si trovino nella stessa partizione. In questo caso, il servizio esegue l'hashing della chiave e la instrada alla partizione corrispondente. L'aggiornamento del numero di partizioni può causare problemi non ordinati a causa della modifica dell'hashing. Pertanto, se si è interessati all'ordinamento, assicurarsi che l'applicazione usi tutti gli eventi delle partizioni esistenti prima di aumentare il numero di partizioni.
  • Mittente round robin (impostazione predefinita): in questo scenario, il servizio Hub eventi esegue il round robin degli eventi tra le partizioni e usa anche un algoritmo di bilanciamento del carico. Il servizio Hub eventi riconosce le modifiche al numero di partizioni ed eseguirà l'invio a nuove partizioni entro pochi secondi dalla modifica del numero di partizioni.

Client destinatari/consumer

Hub eventi fornisce ricevitori diretti e una semplice libreria consumer denominata Processore di eventi.

  • Destinatari diretti: i destinatari diretti restano in ascolto di partizioni specifiche. Il comportamento di runtime non è influenzato quando le partizioni vengono scalate orizzontalmente per un hub eventi. L'applicazione che usa destinatari diretti deve occuparsi di raccogliere le nuove partizioni e di assegnare i destinatari di conseguenza.

  • Host del processore di eventi: questo client non aggiorna automaticamente i metadati dell'entità. Non esegue quindi alcun rilevamento all'aumento del numero di partizioni. La ricreazione di un'istanza del processore di eventi determina il recupero dei metadati di un'entità, che a sua volta crea nuovi BLOB per le partizioni appena aggiunte. I BLOB preesistenti non saranno interessati. È consigliabile riavviare tutte le istanze del processore di eventi per garantire che tutte le istanze riconoscano le partizioni appena aggiunte e che il bilanciamento del carico venga gestito correttamente tra i consumer.

    Se si usa la versione precedente di .NET SDK (WindowsAzure.ServiceBus), l'host del processore di eventi rimuove un checkpoint esistente al riavvio se il numero di partizioni nel checkpoint non corrisponde al numero di partizioni recuperato dal servizio. Questo comportamento può avere un effetto sull'applicazione.

    Il 30 settembre 2026 verranno ritirati le librerie bus di servizio di Azure SDK WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Il supporto del protocollo SBMP verrà terminato, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

    Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio di ritiro del supporto.

Client Apache Kafka

Questa sezione descrive in che modo si comportano i client Apache Kafka che usano l'endpoint Kafka di Hub eventi di Azure quando il numero di partizioni viene aggiornato per un hub eventi.

I client Kafka che usano Hub eventi con il protocollo Apache Kafka si comportano in modo diverso rispetto ai client dell'hub eventi che usano il protocollo AMQP. I client Kafka aggiornano i metadati una volta ogni metadata.max.age.ms millisecondi. Questo valore viene specificato nelle configurazioni client. Le librerie librdkafka usano la stessa configurazione. Gli aggiornamenti dei metadati indicano ai client le modifiche di servizio, incluso l'aumento del numero di partizioni. Per un elenco delle configurazioni, vedere Configurazioni di Apache Kafka per Hub eventi.

Client mittenti/producer

I producer stabiliscono sempre che le richieste di invio contengano la destinazione della partizione per ogni set di record prodotti. Quindi, tutto il partizionamento di produzione viene eseguito sul lato client con la visualizzazione dei metadati del broker da parte del producer. Una volta aggiunte le nuove partizioni alla visualizzazione dei metadati del producer, sono disponibili per le richieste del producer.

Client destinatari/consumer

Quando un membro del gruppo di consumer esegue un aggiornamento dei metadati e preleva le partizioni appena create, il membro avvia il ribilanciamento del gruppo. I metadati del consumer vengono quindi aggiornati per tutti i membri del gruppo e le nuove partizioni vengono assegnate dal responsabile del ribilanciamento assegnato.

Consigli

  • Se si usa la chiave di partizione con le applicazioni producer e l'ordinamento in una partizione dipende dall'hashing della chiave, non è consigliabile aggiungere partizioni in modo dinamico.

    Importante

    Mentre i dati esistenti mantengono l'ordinamento, l'hashing della partizione viene interrotto per i messaggi con hashing dopo la modifica del numero di partizioni a causa dell'aggiunta di partizioni.

  • L'aggiunta di una partizione a un argomento o a un'istanza di hub eventi esistente è consigliata nei casi seguenti:

    • Quando si usa il metodo predefinito per l'invio di eventi
    • Strategie di partizionamento predefinite di Kafka, ad esempio : strategia dell'assegnatare sticky

Passaggi successivi

Per altre informazioni sulle partizioni, vedere Partizioni.