Risoluzione

I consumatori di Apache Kafka fanno generalmente parte di un gruppo di consumatori. Ogni consumatore del gruppo di consumatori riceve messaggi da un diverso sottoinsieme di partizioni dell'argomento quando si verifica quanto segue:

• Più consumatori si iscrivono a un argomento.
• Questi consumatori appartengono allo stesso gruppo di consumatori.

Quando un consumatore non riesce a raggiungere il cluster, il coordinatore del gruppo rimuove il consumatore dal gruppo di consumatori. Questo processo avvia un evento di riequilibrio che include le seguenti azioni:

• I restanti consumatori vengono sollevati dalle partizioni.
• Il coordinatore del gruppo ridistribuisce le partizioni dell'argomento ai restanti consumatori.

Il tuo gruppo di consumatori potrebbe riequilibrarsi alle seguenti condizioni:

• La proprietà della partizione è stata spostata da un utente all'altro in un gruppo di consumatori.
• Hai aggiunto un nuovo consumatore al gruppo di consumatori.
• Un consumatore chiude, si blocca o abbandona il gruppo di consumatori.
• Hai modificato gli argomenti e si verifica un riallineamento delle partizioni.
• C'è un problema di configurazione del client negli abbonamenti per gruppi di consumatori. Ciò deriva da una mancata corrispondenza tra gli argomenti sottoscritti dal gruppo e l'argomento assegnato a ogni singolo consumatore del gruppo.

I consumatori all'interno dello stesso gruppo di consumatori non possono continuare a consumare dati fino al completamento dell'evento di ribilanciamento. Questo è il comportamento predefinito dell'assegnazione delle partizioni. Puoi evitarlo modificando la strategia di assegnazione delle partizioni in CooperativeStickyAssignor.

Per evitare che il tuo gruppo di consumatori si riequilibri continuamente, prova quanto segue:

• Riduci il valore max.partition.fetch.bytes o aumenta il valore del timeout della sessione (session.timeout.ms) nella configurazione consumer. Il consumatore deve chiamare poll() frequentemente per evitare il timeout della sessione e il successivo ribilanciamento. Se la quantità di dati restituita da un singolo poll() è elevata, l'utente potrebbe impiegare molto tempo per elaborare i dati. Ciò significa che il consumatore non arriva alla prossima iterazione del ciclo di sondaggio in tempo per evitare un timeout della sessione.
  Nota: l'impostazione di un valore più alto per session.timeout.ms riduce la possibilità di un ribilanciamento accidentale. Tuttavia, potrebbe essere necessario più tempo per rilevare un guasto reale. Questo parametro è correlato a heartbeat.interval.ms. Il parametro heartbeat.interval.ms controlla la frequenza con cui il metodo KafkaConsumer poll() invia un heartbeat al coordinatore del gruppo. Tuttavia, il parametro session.timeout.ms controlla per quanto tempo un consumatore può resistere senza inviare un heartbeat.
  Ad esempio, supponiamo di eseguire Apache Kafka 0.10.1 o versione successiva e di gestire i record che richiedono più tempo per essere elaborati. In questo caso, ottimizza max.poll.interval.ms per gestire ritardi più lunghi tra un sondaggio e l'altro per i nuovi record.
• Assicurati che il valore session.timeout.ms nella configurazione consumer sia inferiore a quello di group.max.session.timeout.ms nella configurazione del broker.
• max.poll.interval.ms pone un limite superiore alla quantità di tempo in cui il consumatore può rimanere inattivo prima di recuperare altri record. Per impostazione predefinita, questo valore è impostato su 5 minuti. Se questo valore è impostato su meno di 5 minuti, aumentalo per ridurre la possibilità di riequilibrio. Puoi anche considerare la riduzione di max.poll.records insieme a max.poll.interval.ms.
• heartbeat.interval.ms è il tempo previsto tra gli heartbeat e il coordinatore dei consumatori quando utilizzi le strutture di gestione del gruppo di Kafka. Gli heartbeat vengono utilizzati per garantire che la sessione dell'utente rimanga attiva. Facilitano il riequilibrio quando nuovi consumatori entrano o escono dal gruppo. Questo valore deve essere impostato su un valore inferiore a session.timeout.ms. In genere, questo valore deve essere impostato su un valore non superiore a un terzo di session.timeout.ms. Puoi scegliere di ridurre il valore heartbeat.interval.ms a un valore molto più basso per controllare il tempo previsto per i normali riequilibri.
• Se di recente hai eseguito una riassegnazione delle partizioni che comporta modifiche alle partizioni in uno degli argomenti sottoscritti del gruppo di consumatori, il gruppo di consumatori potrebbe riequilibrarsi. Questo perché le partizioni coinvolte vengono spostate o modificate. In questo caso, evita di riavviare il coordinatore del gruppo o altri broker Kafka. È necessario attendere il completamento della riassegnazione della partizione prima di provare a impedire il ribilanciamento del gruppo di consumatori. È consigliabile riassegnare le partizioni durante i periodi di traffico ridotto.

In alcuni casi, potresti visualizzare le seguenti informazioni nei log dei broker Amazon MSK:

[2023-03-01 01:23:45,678] INFO [GroupCoordinator 1]: Preparing to rebalance group amazon.msk.canary.group.broker-1 in state PreparingRebalance with old generation 382660 (__consumer_offsets-21) (reason: Adding new member consumer-amazon.msk.canary.group.broker-1-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx with group instance id None) (kafka.coordinator.group .GroupCoordinator)

Questo messaggio indica che amazon.msk.canary.group.broker-N è nello stato PreparingRebalance.

I gruppi amazon.msk.canary.group.broker-N sono gruppi di consumatori interni che vengono aggiunti o rimossi regolarmente per controllare lo stato e le metriche diagnostiche del cluster. Questi gruppi sono di dimensioni trascurabili e non possono essere eliminati. Puoi ignorare questo messaggio.

Informazioni correlate

Gruppo di consumatori bloccato nello stato di PreparingRebalance