Condividi tramite

Configurazioni consigliate per i client Apache Kafka

  • Articolo

Di seguito sono riportate le configurazioni consigliate per l'uso di Hub eventi di Azure da applicazioni client Apache Kafka.

Proprietà di configurazione client Java

Configurazioni producer e consumer

Proprietà Valori consigliati Intervallo consentito Note
metadata.max.age.ms 180000 (approssimativo) < 240000 È possibile ridurre le modifiche ai metadati prima.
connections.max.idle.ms 180000 < 240000 Azure chiude l'inattività > TCP in ingresso 240.000 ms, che può comportare l'invio su connessioni non riuscite (illustrato come batch scaduti a causa del timeout di invio).

Solo configurazioni del produttore

Le configurazioni del produttore sono disponibili qui.

Proprietà Valori consigliati Intervallo consentito Note
max.request.size 1000000 < 1046528 Il servizio chiuderà le connessioni se vengono inviate richieste superiori a 1.046.528 byte. Questo valore deve essere modificato e causerà problemi in scenari di produzione ad alta velocità effettiva.
retries > 0 Potrebbe essere necessario aumentare delivery.timeout.ms valore, vedere la documentazione.
request.timeout.ms 30000 .. 60000 > 20000 Hub eventi verrà predefinito internamente a almeno 20.000 ms. Anche se le richieste con valori di timeout inferiori vengono accettate, il comportamento del client non è garantito.

Assicurarsi che il request.timeout.ms sia almeno il valore consigliato di 60000 e il session.timeout.ms sia almeno il valore consigliato di 30000. Avere queste impostazioni troppo basse potrebbe causare timeout del consumer, che quindi causano ribilanciamenti (che quindi causano più timeout, che causano più ribilanciamento e così via).
metadata.max.idle.ms 180000 > 5000 Controlla quanto tempo il produttore memorizza nella cache i metadati per un argomento inattiva. Se il tempo trascorso dall'ultima produzione di un argomento supera la durata dell'inattività dei metadati, i metadati dell'argomento vengono dimenticati e l'accesso successivo forza una richiesta di recupero dei metadati.
linger.ms > 0 Per scenari con velocità effettiva elevata, il valore di linger deve essere uguale al valore tolerabile più alto per sfruttare il batch.
delivery.timeout.ms Impostare in base alla formula (request.timeout.ms + linger.ms) * retries.
compression.type none Compressione attualmente non supportata.

Solo configurazioni consumer

Le configurazioni consumer sono disponibili qui.

Proprietà Valori consigliati Intervallo consentito Note
heartbeat.interval.ms 3000 3000 è il valore predefinito e non deve essere modificato.
session.timeout.ms 30000 6000 .. 300000 Iniziare con 30000, aumentare se si vede frequente ribilanciamento a causa di heartbeat mancanti.

Assicurarsi che il request.timeout.ms sia almeno il valore consigliato di 60000 e il session.timeout.ms sia almeno il valore consigliato di 30000. Avere queste impostazioni troppo basse potrebbe causare timeout del consumer, che quindi causano ribilanciamenti (che quindi causano più timeout, che causano più ribilanciamento e così via).
max.poll.interval.ms 300000 (impostazione predefinita) >session.timeout.ms Usato per il timeout di ribilanciamento, quindi non deve essere impostato troppo basso. Deve essere maggiore di session.timeout.ms.

proprietà di configurazione librdkafka

Il file di configurazione principale librdkafka (collegamento) contiene descrizioni estese per le proprietà seguenti.

Configurazioni producer e consumer

Proprietà Valori consigliati Intervallo consentito Note
socket.keepalive.enable true Necessario se la connessione deve essere inattiva. Azure chiuderà l'inattività > TCP in ingresso 240.000 ms.
metadata.max.age.ms ~ 180000 < 240000 È possibile ridurre le modifiche ai metadati prima.

Solo configurazioni del produttore

Proprietà Valori consigliati Intervallo consentito Note
retries 2 Il valore predefinito è 2147483647.
request.timeout.ms 30000 .. 60000 > 20000 Hub eventi verrà predefinito internamente a almeno 20.000 ms. librdkafka il valore predefinito è 5000, che può essere problematico. Anche se le richieste con valori di timeout inferiori vengono accettate, il comportamento del client non è garantito.
partitioner consistent_random Vedere la documentazione di librdkafka consistent_random è predefinito e migliore. Le chiavi vuote e Null vengono gestite idealmente per la maggior parte dei casi.
compression.codec none Compressione attualmente non supportata.

Solo configurazioni consumer

Proprietà Valori consigliati Intervallo consentito Note
heartbeat.interval.ms 3000 3000 è il valore predefinito e non deve essere modificato.
session.timeout.ms 30000 6000 .. 300000 Iniziare con 30000, aumentare se si verifica un ribilanciamento frequente a causa di heartbeat mancanti.
max.poll.interval.ms 300000 (impostazione predefinita) >session.timeout.ms Usato per il timeout di ribilanciamento, pertanto non deve essere impostato su un valore troppo basso. Deve essere maggiore di session.timeout.ms.

Note aggiuntive

Vedere la tabella seguente degli scenari di errore comuni correlati alla configurazione.

Sintomi Problema Soluzione
Errori di commit offset a causa del ribilanciamento Il consumer è in attesa troppo lungo tra le chiamate a poll() e il servizio sta allontanando il consumer dal gruppo. Sono disponibili diverse opzioni:
  • Aumentare il timeout di elaborazione del polling (max.poll.interval.ms)
  • Ridurre le dimensioni del batch di messaggi per velocizzare l'elaborazione
  • Migliorare la parallelizzazione dell'elaborazione per evitare di bloccare consumer.poll()
L'applicazione di una combinazione dei tre è probabilmente più saggia.
Eccezioni di rete ad alta velocità effettiva Si usa il client Java + max.request.size predefinito? Le richieste potrebbero essere troppo grandi. Vedere Configurazioni Java precedenti.

Passaggi successivi

Vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi per le quote e i limiti di tutti i servizi Azure.